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Foreword 


This  document  is  a transcription  of  an  audio  recording  of  presentations  and  discussions  from  the 
Third  NIST  Workshop  on  the  Development  of  Machine  Tool  Performance  Models  and  Data 
Repository.  The  purpose  of  this  workshop  is  to  present  and  discuss  the  progress  in  NIST  work  as 
well  as  industrial  and  academic  collaborators’  work  focused  on  the  development  of  machine  tool 
performance  models  and  data  repository.  Extensive  discussions  were  held  to  review  the  current 
and  future  needs  of  industry  in  using  such  data  repositories  and  associated  analysis  tools  to 
estimate  performance  capabilities.  The  results  of  discussions  are  a prioritization  of  tasks  and 
establishment  of  a timetable  to  satisfy  the  needs  of  the  collaborators.  The  primary  focus  of  the 
document  was  to  capture  major  points  from  presentations  and  discussions  rather  than  a word  for 
word  account  of  the  meeting.  The  presentations  with  corresponding  discussions  are  summarized 
and  given  in  the  main  body  of  this  document,  with  slides  from  most  of  the  presentations  provided 
in  the  Appendix.  The  discussion  of  the  road  map  of  the  program  is  also  summarized  and  given  in 
the  main  body  of  this  document,  with  slides  and  a Gantt  Chart  resulting  from  the  discussion 
presented  in  the  Appendix. 
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Introduction 
Alkan  Donmez 

National  Institute  of  Standards  & Technology 


To  reduce  costs  and  respond  rapidly  to  changing  customer  needs,  large  companies  are  relying 
increasingly  on  a network  of  suppliers  and  outsourcing  a significant  percentage  of  their 
manufacturing  needs.  This  type  of  geographically;  and  organizationally;  distributed 
manufacturing  requires  better  communication  and  improved  coordination  and  utilization  of 
internal  and  external  manufacturing  resources  by  all  the  participants. 

The  goal  of  this  project  is  to  develop  tools  that  enable  design  and  manufacturing  engineers  to 
predict  machine  tool  performance  and  ensure  that  parts  can  be  machined  to  specification  with  a 
minimum  of  prototyping.  [Slide  1-2].  These  tools  include  data  structures  and  low  order  machine 
models  that  represent  actual  machine  behavior,  mathematical  representation  of  actual  part 
geometry,  including  dimension  and  form  errors;  virtual  machining  algorithms;  virtual  inspection 
algorithms;  standardized  data  formats;  and  remotely  accessible  machine  data  repositories. 

This  project  aims  to  replace  actual  machining  and  inspection  of  parts  during  prototyping  with 
virtual  machining  and  virtual  inspection  modules  incorporated  into  a Computer  Aided 
Design/Computer  Aided  Manufacturing  (CAD/CAM)  system.  The  virtual  machining  module  will 
simulate  the  movement  of  the  cutting  tool  when  making  a part.  In  this  simulation,  the  effects  of 
error  motions,  predicted  from  machine-tool  characterization  data  will  be  reflected  in  the  tool  path. 
Virtual  machining  will  result  in  an  electronic  approximation  of  the  part  that  can  be  inspected  by 
the  virtual  inspection  module.  The  virtual  inspection  module  will  determine  the  uncertainties 
associated  with  the  selected  inspection  plans  and  equipment.  These  uncertainties  will  be  checked 
against  the  specified  design  tolerances  of  the  part.  This  virtual  environment  will  make  it  possible 
to  optimize  the  manufacturing  process  by  trying  different  machines  and  making  changes  to  the 
process  plans  or  part  designs. 

There  are  various  needs  that  we  are  addressing  in  this  effort.  [Slide  1-3].  Machine  and  process 
capability  evaluation,  machine  performance  tracking,  capacity  planning,  maintenance  planning, 
inspection  planning  and  algorithm  evaluation  are  among  these  needs. 

A major  challenge  in  creating  a virtual  manufacturing  environment  is  the  representation  of  the 
performance  and  capabilities  of  various  machine  tools.  [Slide  1-4].  Currently,  there  are  no 
provisions  in  machine  tool  or  Coordinate  Measuring  Machine  (CMM)  standards  to  store  the 
performance  information  in  any  electronic  media.  The  lack  of  standard  representation  prevents 
the  creation  of  machine  data  repositories  that  are  needed  to  test  different  simulation  algorithms 
and  to  compare  the  performance  of  a given  machine  against  many  other  machines  within  a similar 
category.  In  order  to  overcome  this  problem,  with  your  help,  we  are  developing  a data  dictionary 
along  with  a standard  format  for  representing  meaningful  machine  performance  data.  We  have 
developed  an  experimental  web-based  repository  to  accommodate  this  data  format.  The  other 
challenges  are  to  develop  virtual  machining  and  inspection  models,  to  communicate  these  models 
throughout  various  companies  and  to  interface  these  models  to  different  software  packages. 

The  first  of  the  two  previous  workshops  (September  1996)  concentrated  on  the  identification  of 
the  above-mentioned  needs.  At  the  second  workshop  (February  1997),  the  aim  was  to  evaluate 
the  status  of  the  program  and  identify  the  future  directions.  [Slide  1-5].  The  main  topics  at  the 
second  workshop  were  machine  tool  metrology  and  information  modeling,  data  requirements  and 
formats  for  machine  performance  evaluation,  prototype  web-based  repository  development  at  the 
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National  Institute  of  Standards  & Technology  (NIST),  interim  machine  check  (importance  and 
storage/communication  of  information),  simulation  tools  (current/future  capabilities  and  needs), 
and  representation  of  the  machined  part.  Sign  conventions  were  also  discussed  but  no 
conclusions  have  been  reached  so  far.  [Slide  1-6].  Frequency  content  (spatial  and  time  domain) 
of  performance  data  and  how  to  use  this  information  for  error  budgeting  was  discussed.  Machine 
and  process  interactions  and  tools  to  address  these  issues  were  discussed.  Machine  and 
environment  interaction  and  how  to  capture  this  information  in  repository  were  discussed  at 
length.  The  need  for  including  the  physical  description  of  machine  in  the  repository  was 
identified.  [Slide  1-7].  Economic  performance  information  to  aid  with  capacity  and  process 
planning  to  include  scrap  rates  for  the  estimation  of  cost  of  using  a particular  machine  was 
discussed.  Storage  and  structure  of  data  and  models  in  the  repository  were  discussed.  The  use  of 
data  models  in  repository  to  visualize  machine  behavior  for  maintenance  issues  of  machine  was 
also  discussed.  In  addition  to  detailed  data  and  information  models,  we  need  tools  to  translate  the 
information  to  simple  and  concise  results  such  that  management  and  decision  makers  can  be 
briefed  of  the  machine  issues.  Performance  tracking  by  part  probing  was  discussed  but  no 
conclusions  were  reached.  Graphical  representation  of  machined  part  was  discussed.  [Slide  1-8]. 
High  level  information  extracted  from  repository  for  simulation  tools  was  a requirement  from  the 
software  developers  since  raw  data  needs  processing  prior  to  interfacing  with  software  packages. 
Three  different  types  of  simulation  approaches  were  discussed:  (1)  only  part  (design  issues),  (2) 
part  and  machine  interaction  (process  planning  issues),  or  (3)  machine  only  (for  diagnostic 
purposes).  Accuracy  versus  speed  compromise  in  simulation  tools  was  addressed.  Finally, 
information  storage  requirements  in  three  categories  were  discussed:  (1)  machine  only,  (2) 
instrument  used  to  measure  machine,  (3)  measurement  related  issues. 

The  consensus  of  the  previous  two  workshops  is  that  virtual  manufacturing  is  needed.  [Slide  1-9]. 
It  is  a big  goal.  As  for  the  immediate  tasks,  we  need  to  concentrate  on  machine  errors,  how  those 
errors  relate  to  part  errors,  information  model,  and  file  formats.  Once  these  features  are  captured 
in  the  repository,  we  can  go  to  the  next  steps  of  virtual  manufacturing.  A road  map  will  be 
discussed  at  the  conclusion  of  this  workshop. 

Some  action  items  were  identified  at  the  last  meeting.  In  order  to  capture  and  properly  use  any 
information  in  the  repository,  we  need  to  have  a data  dictionary.  [Slide  1-10].  We  demonstrated 
an  experimental  repository  (tools  and  procedures),  the  next  step  was  to  import  data  and  test  the 
repository.  Another  action  item  was  to  establish  a consortium  so  that  people  can  start  accessing 
the  repository  prior  to  public  access  and  to  establish  a more  effective  means  of  communication 
between  participants.  In  addition,  the  need  for  a road  map  was  emphasized. 

In  this  meeting,  we  will  present  a draft  data  dictionary  that  we  have  developed  since  our  last 
meeting.  [Slide  1-11].  Comments,  modifications,  and  additions  to  this  data  dictionary  are 
needed.  We  have  started  importing  data  into  the  repository.  Boeing  and  Caterpillar  have 
uploaded  data.  Storage  and  analysis  are  performed  on  the  data.  Three  Cooperative  Research  and 
Development  Agreement  (CRADA)  agreements  have  been  completed  and  five  are  still  pending. 
In  this  workshop,  we  will  review  what  each  of  us  has  been  doing  since  the  last  meeting.  Data 
dictionary,  repository  and  analysis  tools,  simulation  tools,  and  a draft  road  map  will  be  discussed. 
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Factory  Computing  Architecture: 

A Key  Component  of  Boeing’s  2016  Vision 
Martin  Kitna 
Boeing,  Seattle 


Several  weeks  ago,  there  was  a “Factory  Computing  Architecture  Users’  Conference”  that 
brought  a large  number  of  people  together  to  discuss  technical  matters  as  they  relate  to  Boeing 
factories.  This  presentation  is  a collection  of  charts  and  graphs  from  several  presentations.  They 
were  prepared  by  the  Factory  Computing  Architecture  (FCA)  Program,  myself,  and  what  we  in 
the  Measurement  Domain--which  includes  machine  tool  accuracy,  coordinate  measurement 
machines,  on  machine  probing,  numerical  control  machines,  statistical  process  control,  hardware 
variability  control  (decisions  made  in  your  engineering  areas  before  you  actually  know  what  to 
measure  in  terms  of  statistical  process  control  and  other  similar  things). 

What  is  Factory  Computing  Architecture?  First  of  all  it  is  a strategic  effort  that  will  take  at  least  a 
few  years  to  accomplish.  It  is  essentially  a set  of  computing-based  strategies,  which  enable 
factories  to  implement  our  company’s  initiatives.  [Slide  2-2].  Our  executives  might  say  “go 
make  significant  improvements  in  a particular  area”,  but  when  you  look  at  the  underlying 
computing  technology  that  is  in  our  factories,  we  are  finding  that  it  is  very  challenging  to 
implement  the  initiatives  that  we  are  trying  to  achieve  due  to  variation  in  computing  technologies 
and  applications  in  use  around  Boeing.  In  short,  some  standardization  needs  to  be  defined  and 
implemented  for  computing  technology  used  in  Boeing  factories.  This  is  a guiding  principle  of 
Boeing's  Factory  Computing  Architecture  Program.  An  integrated  Factory  Computing 
Architecture  will  enable  our  factories  to  be  more  flexible  and  better  able  to  change  as  business 
needs  dictate  so  that  when  initiatives  or  needs  for  improvement  arise  in  the  future,  we  are  able  to 
react  in  a more  responsive  manner.  We  want  to  assure  connectivity  to  upstream  and  downstream 
data,  and  functionality  for  future  integration. 

How  do  we  capture  all  of  this?  We've  developed  some  computing  architecture  frameworks  to 
“forecast  the  future”  of  factory  technological  needs.  As  we  document  technical  standards  and 
product  standards,  we  then  develop  transition  plans  for  what  we  call  domains  and  technology 
pictorial  representations.  We  are  also  doing  some  use-case  modeling  of  certain  factory  business 
processes  that  have  been  identified  as  candidates  for  computing  architecture  improvements.  The 
use  of  CASE  modeling  is  an  object  oriented  method  of  identifying  all  of  the  actions  that  a 
particular  business  process  possesses  and  all  of  the  relevant  types  of  information  that  flow  into 
and  out  of  that  process.  That  is  important  for  reuse  down  the  stream.  When  we  develop 
applications,  we  like  to  be  able  to  develop  ones  that  we  can  reuse  many  times.  We  also  have  a 
notion  of  a factory  upgrade  process.  Right  now,  we  have  silos  of  activity  that  are  involved  when 
we  upgrade  our  factory  when  we  respond  to  production  increases.  There  needs  to  be  integration 
among  those  processes.  What  you  get  is  one  group  coming  in  with  a new  machine,  they  do  their 
job  while  not  necessarily  being  cognizant  of  how  they’re  affecting  other  groups  that  need  to  also 
be  involved.  So  the  notion  of  a factory  upgrade  process  is  to  work  that  situation  out  and  to  make 
it  more  efficient. 

Integrated  Factory  Computing  Architecture  is  going  to  change  the  way  we  do  business  with  our 
supplier  community.  [Slide  2-3].  Right  now,  in  our  factory  information  systems,  there  is  a lot  of 
proprietors  in  machine  controllers  that  makes  it  difficult  to  develop  broad-based  applications  that 
get  information  from  many  different  machines  because  developing  individual  machine  interfaces 
is  costly  and  time  consuming.  It  is  our  goal  to  change  that  by  advocating  the  use  of  Open 
Architecture  Controllers,  we'll  be  able  to  begin  to  turn  the  proprietary  situation  around.  One  of 
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the  key  messages  to  our  supplier  community  is  to  incorporate  products  in  their  business  strategies 
supporting  open  architecture  controllers  and  our  transition  efforts. 

This  is  a chart  showing  visions  for  the  year  2016.  [Slide  2-4].  There  are  some  starred  items  on  it 
of  interest  to  the  FCA  program.  The  notion  of  being  a global,  international  enterprise;  design 
anywhere,  build  anywhere  is  something  that  we’re  interested  in.  Our  management’s  role  is  to 
support  inter-team  communications.  Boeing  is  organized  to  include  special,  small  business  units 
and  process-oriented  organizations,  which  ensure  process  commonality  across  the  company.  In 
addition,  the  FCA  program  staff,  is  a small  central  organization,  which  provides  technology 
integration  services  to  many  different  organizations  supporting  Boeing  factories. 

I’ll  go  ahead  and  show  this  chart  again.  [Slide  2-5].  I just  talked  about  this  on  the  other  chart.  It 
is  basically  global  enterprise,  lean  efficient  design  and  production,  small  business  units,  small 
central  organization  for  integration,  people  and  culture  integration. 

Cross-functional  integration.  [Slide  2-6].  This  is  very  important;  where  we  talk  about  moving 
away  from  “silo  activity”  that  you  get  from  large  company  activities  and  more  towards  cellular 
and  getting  many  different  organizations  working  together.  At  the  top  we  have  what  our 
company  invests  in~specialty  disciplines.  We  have  specialists  in  tool  design,  manufacturing 
engineering,  manufacturing  research  & development,  quality  assurance,  facilities  and  information 
systems.  Those  are  all  silos;  they  have  different  roles  to  play  in  what  we  call  the  factory  upgrade 
process.  The  wording  underlying  the  factory  upgrade  process  are  processes  that  we  know  of  that 
have  an  impact  on  upgrading  our  factories.  Those  are  the  processes  (lean  manufacturing 
assessment,  capacity  analysis,  new  equipment  introduction,  etc.)  that  need  to  be  integrated.  From 
there,  we  want  to  develop  some  tools  that  will  enable  coordinated  delivery  of  technical  standards, 
specifications  and  rules,  into  our  integrated  product  teams  which  bring  all  of  these  different  areas 
together  and  focus  on  upgrading  our  factories. 

This  is  another  way  of  looking  at  Integrated  Product  Teams  (IPTs).  [Slide  2-7].  We  have  the 
discipline  owners  cutting  across  several  different  business  units  (machine  parts,  sheet  metal, 
assembly  areas  for  727  and  757,  and  larger  airplanes,  etc.).  This  chart  is  dynamic. 

This  chart  shows  the  scope  of  the  Factory  Computing  Architecture  Program.  [Slide  2-8].  The 
portion  above  the  center  line  is  what  our  enterprise  level  initiatives  are,  besides  manufacturing, 
which  involves  product  definition,  build  materials  and  process  planning  and  asset  management 
which  involves  the  management  of  factory  machine  tools,  the  actual  buildings  that  they’re  in, 
even  down  to  the  air  conditioning  of  the  factory.  Below  the  line  is  the  factory  specific  stuff, 
where  we  have  the  machine  controllers  and  cell  controllers.  There's  a feed  for  digital 
manufacturing  data  sets.  Those  come  in  and  are  then  executed  on  the  machine.  There's  the 
measure  and  analyze  quality,  which  is  my  area.  Monitoring  machine  performance,  I am  involved 
with  that  and  performing  maintenance  operations.  One  of  the  key  things  that  had  to  happen  was, 
at  Boeing  because  of  the  mentality  which  exists  in  certain  parts  of  the  company,  we  had  to  bring 
the  facilities  people  into  this  effort.  The  reason  why  is  that  they  have  the  money  and  expertise  of 
the  factory  machines,  maintaining  and  upgrading  them.  That’s  the  scope. 

This  is  one  of  the  types  of  frameworks  that  we  have  been  developing.  [Slide  2-9].  We  have  a 
notion  of  information  level,  which  is  the  top  layer.  We  have  our  factory  workstations,  data 
collection  and  applications,  things  like  wireless  networking  and  things  like  that,  upstream 
computing  systems.  We  have  a high  level,  which  goes  up  into  our  main  business  system.  At  the 
control  level,  we  have  our  cell  control  workstations.  At  the  device  level  is  where  we  get  down  to 
the  nitty  gritty;  we  have  our  machine  tools,  machine  controllers,  data  collection  devices  of  our 
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machines  and  sensors.  We  also  have  this  notion  of  non-real-time  at  the  top,  near  real-time  and 
hard  real-time.  I think  there  is  only  two  categories.  Hard  real-time  is  when  you  are  making 
something,  you’re  getting  data,  and  you  are  able  to  interact  with  the  controller. 

Focus  of  factory  computing  architecture.  [Slide  2-10].  An  existing  factory  situation  with  benefits 
to  our  program,  we  have  emerging  business  processes,  then  we  have  strategies.  “Existing  factory 
situation”  is  where  we  build  a consistent  factory  upgrade  processes.  [Slide  2-11].  As  I said 
before,  we  have  people  coming  in,  in  a disjointed  fashion  to  upgrade  our  factories.  We  have 
variation  in  factory  sub-component  functionality,  split  responsibilities  for  the  factory  computing 
architecture,  undocumented  standards,  which  is  changing  as  the  program  is  developed.  If  the 
cycle  time  for  change  is  too  lengthy,  we're  aren't  able  to  reap  benefits  projected  by  our  initiatives. 

We  want  to  simplify  our  manufacturing  process  before  automation.  [Slide  2-12].  We  want 
quality  control  to  occur  via  process  acceptance.  We  want  to  get  away  from  single  item 
inspection,  we  want  to  work  towards  accepting  our  products  based  upon  process  information.  As 
part  of  that,  we  need  reliable  machines  for  production.  Digitally  controlled  manufacturing.  It 
would  be  nice  to  go  from  our  design  process,  push  a button,  and  then  have  our  parts  produced. 

We  have  a lot  of  overhead  between  our  design  system  and  our  production  system. 

Emerging  business  processes.  [Slide  2-13].  We  want  reliable  and  repeatable  factory  upgrade 
processes.  Where  we  can  deploy  our  technical  product  standards,  we  want  modular,  integrated 
products,  pulled  by  customers,  we  want  to  move  from  proprietary  systems  and  evolve  to  open, 
modular  architecture,  and  we  want  more  up-front  consideration  of  software  requirements. 

This  chart  is  our  current  factory  upgrade  process.  [Slide  2-14].  We  have  engineering  design  and 
build  up  here  at  the  top.  When  our  software  step  starts  to  happen  products  are  already  starting  to 
be  produced.  The  software  activity  occurs  too  late  in  the  process.  The  preferred  way  is  to  move 
the  software  design,  building  and  integration  much  more  forward  in  the  process  so  that  the 
software  that  comes  out  is  of  higher  quality. 

Benefits  of  the  program.  [Slide  2-15].  Categorized  as  follows:  unit  cost,  cycle  time,  defects,  and 
customer  satisfaction. 

Domains.  [Slide  2-16].  We  have  factory  domains,  which  include  the  creation  of  (Numerical 
Control)  NC  programs,  verification,  simulation,  and  execution.  We  have  measurement,  which 
includes  machine  tool  accuracy,  statistical  process  control,  and  hardware  variability  control.  The 
items  at  the  center,  manufacturing  process  control,  cell  control,  machine  control,  adaptive  control, 
are  specific  to  machines.  Machine  controllers  with  modular  architecture.  Adaptive  control,  to  be 
able  to  adjust  manufacturing  in  real-time  (e.g.,  while  products  are  being  made).  The  next  one  is 
related  to  the  facilities.  We  have  machine  tool  and  equipment  effectiveness.  That’s  not  really  a 
domain  that  has  a management  body,  where  the  others  do.  Right  now  we  are  rolling  this  area 
under  Measurement,  until  this  area  can  stand  on  its  own. 

Tooling.  When  we  had  our  users’  conference,  we  only  had  manufacturing  process  control, 
measurement,  and  numerical  control  and  computing  services.  Computing  services,  think  of  that 
as  your  underlying  support  infrastructure  of  your  network  and  people  who  keep  your  PCs 
running,  and  those  types  of  issues. 

Other  framework  standards.  [Slide  2-17].  By  and  large  for  machine  controllers.  We  also 
introduce  enterprise  standards  and  delivery  system  standards.  I’m  just  giving  you  a flavor  for  the 
work  that  we’re  doing. 


CHANDRA SEKHARAN:  I noticed  that  you  had  64-bit  computing  listed,  would  you  explain 
that. 

KITNA:  It’s  a direction.  This  particular  chart  came  out  of  a target/conceptual  direction  for 
machine  controller  standardization.  Under  the  enterprise  area,  it  shows  64-bit  computing. 

ESTERLING:  Until  you  can  get  NT,  a real-time  operating  system,  then  there  are  kluges  being 
implemented.  The  market  seems  to  be  strongly  going  towards  standard  PC  Windows 
applications,  because  it’s  cheaper. 

KITNA:  In  some  ways.  In  other  ways,  Microsoft’s  back  office  strategy  for  the  enterprise  is 
costly.  Information  Week  had  some  interesting  articles.  Windows  NT  is  a preference,  UNIX  is 
still  in  the  picture.  We  are  not  satisfied  with  real-time  NT  capabilities  as  of  yet.  There  is  a place 
for  it,  and  the  Factory  Computing  Architecture  Program  will  determine  where  NT  is  most 
gainfully  implemented;  in  addition  to  UNIX's  place  in  the  factory  computing  architecture. 

WELSCH:  Share  your  experiences  with  ODBC.1 

KITNA:  We  use  it  for  connectivity  with  databases  (i.e.,  Oracle  or  SQL  Server)  in  the  PC 
environment.  I have  heard  of  some  performance  problems,  but  I don’t  have  first  hand  knowledge. 

I had  mentioned  we  used  some  different  types  of  modeling  (i.e.,  global)  in  various  domain  areas 
that  I described.  [Slide  2-18].  As  an  example,  we  have  a use-case  diagram  for  one  of  our 
business  areas,  the  automated  spar  assembly  tool  which  is  numerically  controlled.  Things  that 
happen  there  are  order  management,  job  management,  machine  tool  data  set  management, 
process  control  (which  includes  measurement  and  statistical  process  control,  machine  part 
programs,  etc.).  Then  you  get  some  interesting- looking  process  communication  diagrams.  These 
types  of  things  can  be,  for  example,  50  pages  per  area  that  you  model.  This  is  just  to  give  you  a 
flavor  of  what  type  of  object  modeling  that  we’re  doing. 

To  quote  my  manager,  “It’s  all  in  the  infrastructure”.  [Slide  2-19].  One  of  the  things  after  Boeing 
started  downsizing  in  ’95,  where  they  had  some  early  retirement  options  being  offered.  From  my 
manager’s  perspective,  that  had  an  impact  on  the  underlying  management  infrastructure.  It  has 
taken  creative  efforts  to  put  back  in  place  what  was  once  there.  Our  initial  authorization  came 
from  the  Boeing  Commercial  Aircraft  Group  (BCAG)  Produce  Process  Management  Board, 
which  is  populated  out  of  discipline  boards  or  specialist  areas  such  as  quality  assurance  and 
facilities,  etc.  We  have  a program  steering  committee,  which  is  cross-functional,  including 
information  systems.  The  program  lists  many  projects  under  the  main  areas  of  the  discipline 
boards.  Then  we  have  an  area  where  we  have  subject  matter  experts  where  we  can  draw  upon 
their  knowledge  to  create  this  architecture. 

Expectations  for  this  year  and  next  year,  we  want  to  establish  an  integrated  architecture  and 
related  management  infrastructure.  [Slide  2-20].  The  integrated  architecture  is  technical, 
infrastructure  is  the  management.  Our  team  is  our  user  community.  We  are  also  partnering  with 
the  automotive  companies  (i.e.,  Chrysler,  General  Motors  (GM),  Ford;  we’ve  also  talked  to 
Saturn).  The  automotive  companies  buy  more  machine  tools.  We  want  to  leverage  their  voice 
with  ours  to  influence  machine  tool  vendors  to  support  our  factory  computing  architecture 
directions.  We  want  to  develop  a multi-year  architecture  deployment  plan  for  each  of  the 


1 Open  Database  Connectivity  (OBDC)  is  Microsoft’s  application  programming  interface  that  enables 
applications  to  access  data  from  a variety  of  existing  data  sources. 
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domains.  We  want  to  convey  our  computing  strategies  and  direction  for  technical  and  product 
standards  to  our  suppliers.  As  a part  of  that,  we  will  be  having  a suppliers  conference  next  year  in 
the  May  time  frame.  We  want  to  work  with  suppliers  to  implement  our  strategies. 

Another  piece  of  the  infrastructure  that  I'd  like  to  discuss  is  that  we  have  what  we  refer  to  as  a 
domain  architect  and  a domain  captain.  The  domain  captain  is  typically  a management  person, 
who  works  in  concert  with  the  domain  architect  to  develop/identify  the  necessary  technical 
product  standards  for  that  given  area  of  business  activity.  The  domain  captain  will  be  more  the 
customer  with  the  non- information  systems  representative  and  the  architect  is  more  the 
information  systems  representative.  I mentioned  that  we  had  a Users’  Conference  several  weeks 
ago.  Our  expectations  for  that  conference  were  to  communicate  factory-computing  architecture 
as  an  enabler  to  implement  BCAG  strategies  in  production.  [Slide  2-21].  We  want  to  establish  a 
level-set  of  all  of  our  initiatives  in  the  various  ongoing  programs.  As  you  may  know,  we 
absorbed  a few  companies  this  year.  Several  representatives  from  Rockwell  were  present  at  the 
conference  and  it  was  very  important  to  get  the  communication  flowing.  In  addition  to  the 
agreements,  issues,  and  action  items  identification,  we  are  going  to  converge  toward  our  factory 
computing  vision.  The  conference  also  served  to  initiate  communications  with  the  new  members 
of  our  team;  to  build  synergy  in  the  various  areas.  We  want  to  understand  how  technical  data  will 
be  delivered  to  our  business  units  and  cross-functional  teams,  which  are  called  IPTs.  As  part  of 
the  factoiy  upgrade  process,  we  started  some  process  integration  in  this  area.  We  want  an 
awareness  of  the  necessity  to  empower  these  steering  committees  in  the  various  boxes  that  I 
showed  in  the  infrastructure  chart  associated  with  the  FCA  program.  It’s  always  a struggle, 
particularly  for  Boeing  when  you  have  large  production  increases  and  you  are  still  trying  to  do 
things  the  same  way.  In  the  information  systems  world,  we  are  all  competing  for  the  same 
resources.  Production  wants  everyone  to  worry  about,  of  course,  production,  yet  we  still  have  to 
worry  about  the  future  and  this  architecture.  By  working  with  the  infrastructure  that  management 
is  putting  into  place,  we  are  able  to  keep  the  momentum  going.  At  the  Users’  Conference  we  had 
executives  come  and  give  us  their  perspectives  on  the  program. 

Another  key  element,  in  addition  to  getting  the  communication  at  the  Users’  Conference,  we  want 
to  gather  all  of  these  different  areas  together  to  understand  the  strategy,  vision,  and  to  set  up  a 
forum  for  the  items  that  I mentioned.  We  want  to  be  able  to  have  one  voice  for  Boeing  to 
communicate  effectively  with  our  suppliers.  We  want  our  suppliers  to  be  able  to  call  anyone 
within  Boeing  and  get  the  same  answer,  no  matter  who  is  called. 

By  bringing  together  all  of  the  process-oriented  folks  and  technology  folks,  we  want  to  get  all  of 
the  process  and  computing  elements  necessary  for  production  together  in  one  place.  [Slide  2-22]. 
On  the  left,  we  have  the  various  initiatives  coming  into  the  factory  area. 

We  have  our  factory  execution  process,  which  is  drawn  from  several  sub-processes.  [Slide  2-24]. 
Our  domains  specify  what  is  within  their  framework.  The  notion  of  the  factory  upgrade  process 
is  included,  where  we  have  a clear  understanding  of  the  component  processes  and  their  inter- 
relationships. We  are  able  to  get  the  tools  in  place  such  that  the  technical  and  product  standards, 
etc.,  can  be  used  in  the  notion  of  the  cost  model;  nothing  is  free. 

This  is  the  highest  level  of  the  Factory  Computing  Architecture  Framework  where  we  have 
various  domains  along  the  top,  the  utilities  layer,  a set  of  standard  application  interfaces  and  the 
delivery  system  hardware  down  at  the  bottom.  [Slide  2-25].  An  example  of  this  is  shown  in  the 
slide.  We  have  domain  business  activity  identified  at  the  top.  Specific  utilities,  whether  we  are 
buying  them  or  creating  them  ourselves.  The  bronze  colored  blocks  are  where  we  start  to  specify 
the  standard  access  methods  per  Boeing  standards,  lists  them  out  like  Standard  Query  Language 
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(SQL),  ODBC,  Data  Objects,  etc..  You  can  see  we  become  very  specific  for  the  standards  we 
want  to  apply. 

WELSCH:  Did  you  consider  other  frameworks  such  as  Enterprise  Management? 

KITNA:  It  was  created  by  the  people  who  work  in  the  area.  I asked  one  of  our  consultants,  and 
she  had  an  example  that  basically  validated  what  we  produced.  The  types  of  frameworks  that  I 
showed  were  developed  along  the  way,  and  Tm  not  aware  of  other  types. 

These  are  the  major  architecture  design  steps  of  the  development  of  the  Factory  Computing 
Architecture  Program.  [Slide  2-26].  We  are  in  Step  1,  where  we  are  defining  the  2-D 
architecture,  which  I have  already  described.  The  next  step  is  to  prepare  the  domain  transition 
plans  that  measure  the  numerical  control,  the  manufacturing  process  control,  and  computing 
services,  etc..  The  domain  transition  plans  will  incorporate  the  moves  to  new  technologies  that 
we  are  forecasting.  That  could  be  64-bit  computing,  where  NT  and  UNIX  lie  in  the  architecture, 
etc..  The  upgraded  factory,  that  is  deploying  or  supporting  the  integrated  product  teams 
throughout  the  next  few  years  to  go  forward  to  upgrade  our  factories.  People  like  me  who 
support  those  efforts.  Business  unit  implementation  plans;  to  make  sure  they  stay  tightly  linked 
to  those  activities. 

This  is  my  last  chart,  which  is  a high  level  view  of  what  we’ve  done  and  where  we  are  going  into 
the  second  quarter  of  next  year.  [Slide  2-27].  We  had  our  Users’  Conference  in  October.  We  had 
a couple  of  white  papers.  At  the  conference,  we  had  a survey  where  we  asked  what  types  of 
technology,  which  were  of  interest;  since  they  were  all  users,  it  was  all  valuable  information.  We 
had  an  initial  list  and  we  asked  them  to  multi-order  them,  then  we  wrote  a white  paper  on  the 
results.  In  addition,  we  had  a white  paper  for  infrastructure.  That  was  the  management 
organization,  which  was  put  into  place  to  make  this  program  grow  into  fruition.  We  made  project 
plans.  Those  essentially  provided  the  visibility  to  essential  projects,  which  can  be  used  at  more 
than  one  site.  We  had  four  domain  project  plans:  (1)  numerical  control,  (2)  manufacturing 
process  control,  (3)  measurement,  and  (4)  computing  services.  I already  talked  about  the 
transition  plans  and  how  we’re  implementing  the  technologies  to  transition  over  time.  Then  the 
second  quarter.  I’ve  already  talked  about  the  Suppliers’  Conference.  The  bottom  bar  is  the 
Factory  Upgrade  Process,  there  should  be  progress  on  that  line  since  we’re  moving  forward  with 
the  factory  upgrade  process  integration,  infrastructure,  white  paper,  teams  that  are  looking  at  the 
upgrade  factories.  I want  to  iterate  that  through  as  we  learn  how  that  process  is  working.  I’ve 
given  an  overview  of  the  Factory  Upgrade  Process,  FCA  Program  Development,  an  overview  of 
what  we’ve  accomplished,  what  we’ve  accomplished  at  the  Users’  Conference  and  what  is 
planned  for  the  future.  Are  there  any  questions? 

DONMEZ:  When  is  the  framework  going  to  be  actually  ready  for  implementation? 

KITNA:  I’d  say  in  the  April/May  time  frame  of  next  year.  Just  because  we  want  to  have  a 
transition  plan  well  understood  before  we  begin  implementation. 

KATTER:  The  asset  management,  will  that  be  controlled  by  a central  unit  or  a business  unit? 

KITNA:  We  have  an  organization  called  FAMO  (Facilities  Asset  Management  Organization).  It 
is  the  Boeing  organization  responsible  for  our  facilities.  It  is  a central  organization  in  the  sense 
that  it  reports  directly  to  our  Group  President,  but  it  is  regional.  We  have  FAMO-North,  which 
would  include  Washington.  We  have  FAMO-South,  which  would  include  Wichita.  How  FAMO 
relates  to  our  new  acquisitions,  that  has  not  been  determined.  It  is  going  to  take  a few  years  to 
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fully  integrate  Rockwell  and  McDonnell  Douglas.  Therefore,  there  are  separate  facilities 
management  organizations  that  handle  these  types  of  issues. 


Machine  Capability  Diagnosis  and  Recovery  System 
Angel  Dahilig  and  Jim  Covington 
Boeing,  Wichita 


COVINGTON:  We’re  having  a tag  team  today.  Angel  Dahilig  is  my  project  manager.  She  will 
talk  for  the  first  half  of  our  talk  on  the  computing  aspects. 

DAHILIG:  We’ve  got  a project  going  on  in  Wichita  that  is  being  considered  as  a candidate  for  an 
enterprise  level  project.  It  is  the  Machine  Capability  Diagnosis  and  Recovery  System  and  we 
call  it  MCDRS.  I am  the  project  manager  on  the  technology  side  and  Jim  Covington  is  the 
Systems  Manager. 

KITNA:  What  is  the  difference  between  a project  manager  and  a systems  manager? 

DAHILIG:  We’re  following  the  P+  methodology  and  they  call  a project  manager  the  person  who 
is  managing  the  actual  product  building  and  delivery,  which  is  like  the  software  engineering  team. 
The  systems  manager  is  the  person  who  is  leading  the  (functional)  process  side  of  the  project 
(user  representative). 

DAHILIG:  This  is  the  agenda.  We  will  talk  about:  what  is  MCDRS,  we’ll  go  over  some  process 
and  data  definition  strategies,  the  MCDRS  web  site,  and  machine  data. 

What  is  MCDRS?  It  supports  some  of  our  Boeing  initiatives.  Supports  reduction  and  variability 
of  numerical  control  machine  parts  by  identifying  and  monitoring  sources  of  machine  error.  It 
will  provide  for  active  corrective-action  planning  and  tracking. 

The  objectives  of  MCDRS  are  to  reduce  part  variability  related  to  machine  performance  errors. 
Reduce  unscheduled  machine  down  time,  specifically  breakdown  times.  Establish  reliable 
methods  and  processes  for  machine  performance  tracking,  and  increasing  the  accountability  and 
visibility  of  machine  performance. 

The  scope  of  MCDRS  is  being  considered  for  enterprise  wide  implementation  for  Computer 
Numerically  Controlled  (CNC)  machines  and  a baseline  for  periodic  machine  inspection  such  as 
ballbar,  laser  diagnostics  of  linear  axes,  and  analysis. 

What  will  MCDRS  do?  MCDRS  will  define  standard  machine  measurements,  plans  and 
schedules.  Capture  machine  measurement  data,  document  and  manage  data.  Provide  automatic 
notification  when  one  of  two  exception  type  situations  occur  such  as  (1)  when  there  is  an  out  of 
control  condition  that  has  been  detected  for  your  expected  machine  parameters  and  (2)  when 
scheduled  measurement  events  occur.  This  addresses  accountability  of  actually  performing  and 
sticking  to  your  plan  of  machine  assessments. 

MCDRS  will  analyze  the  data  to  determine  the  machine  capability  performance  against  planned 
parameters,  predict  out-of-control  machine  performance  deterioration,  analyze  part  family 
compatibility  or  incompatibility  for  a particular  machine  or  machine  class. 

This  system  will  rank  machines  by  performance,  provide  root  cause  error  analyses,  and  provide 
recovery  recommendations  and  documentation.  These  last  two  bullets,  we  plan  to  use 
knowledge-based  processing. 
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Our  Implementation  Plan.  We  are  using  P+  development  methodology.  I’m  not  sure  how  many 
of  you  have  ever  heard  of  P+.  We  are  currently  a SEI/CMM  site  at  level  3.  Boeing,  Wichita 
information  systems  (IS)  is  the  largest  IS  site  to  have  that  level  3. 

WELSCH:  How  did  you  determine  the  level? 

DAHILIG:  We  are  using  P+  as  our  methodology  for  SEI/CMM.  SEI  people  came  in  and 
interviewed  all  of  the  projects,  project  managers.  We’re  official.  Before  they  did  that,  Boeing 
tried  to  analyze  where  we  were  at  to  make  sure  we  were  on  track  for  the  deployment  of  this. 

CMM  means  Capability  Maturity  Model  and  the  whole  idea  behind  that  is  that  you  have  a 
standard  and  repeatable  process  for  software  engineering.  The  preliminary  analysis  phase:  We 
were  originally  scheduled  to  be  completed  the  1st  of  December  with  the  preliminary  analysis 
review  which  is  the  steering  committee  buy  off.  That  will  provide  conceptual  functional  data  and 
process  models  for  the  system. 

Define  business  and  technical  requirements:  Technical  trend  analysis,  additionally  potential  cost 
benefit  analysis  and  implications,  is  scheduled  for  the  rest  of  the  project.  That  is  all  provided  by 
the  Preliminary  Analysis  (PA)  phase.  Because  we’re  planning  on  becoming  an  enterprise 
application,  teaming  is  very  important  and  that  is  a cornerstone  of  our  philosophy  of  MCDRS. 
Teaming,  with  other  Boeing  locations,  we  have  a Boeing  MCDRS  Intranet  site,  which  we’re 
using  as  a communication  tool.  Teaming  also  with  our  suppliers.  This  is  one  of  the  reasons  we 
are  here  now  with  the  NAMT  program,  and  NIST  in  particular,  may  help  us  see  where  our  project 
fits.  Our  software  engineering  team  is  co-located  with  our  system  manager.  That  is  to  help 
facilitate  the  team  inter-communication.  We  plan  to  move  on  to  this  phase  with  system 
construction. 

Data  Subject  (P+  150).  This  is  just  to  give  you  an  idea  of  the  types  of  data.  We  call  it  data  facets, 
groupings  of  data  that  we  will  be  handling  with  our  system.  Everything  within  this  interior 
rectangle  is  actually  MCDRS  “owned”.  When  we  say  “owned”,  that  actually  means  MCDRS  is 
responsible  for  the  creation  of  the  application.  Of  course,  other  systems  can  read  it.  Everything 
interior  to  the  exterior  rectangle  is  data  that  we  may  have  created  with  other  facets.  This  is 
manufacturing  equipment,  and  that  describes  our  machines  and  machine  tools.  Machine  test 
facets:  describes  our  machine  tests  that  are  to  be  performed  (i.e.,  the  frequency  of  the  tests,  type 
of  tests,  parameters  expected  from  that  test).  Test  equipment:  that  defines  our  equipment  that 
we’re  using  to  gather  the  measurements  (configuration).  Machine  test  results:  after  they  perform 
the  assessment  test,  what  they  got,  and  how  we’re  actually  performing. 

HEMMERLE:  Your  expected  machine  capability,  is  that  based  on  type  of  machine  or  on  the 
product  being  produced? 

DAHILIG:  The  machine. 

HEMMERLE:  If  I need  a certain  quality  within  my  work  zone  that  is  based  upon  type  of 
machine  as  opposed  to  the  product,  which  is  going  across  the  machine? 

COVINGTON:  In  this  particular  situation  we  are  talking  about  expected  values  in  terms  from 
historical  data.  We  are  getting  a set  of  outputs  and  this  set  of  outputs  is  within  expected  limits  for 
a family  of  parts. 

HEMMERLE:  So  the  accuracy  requirement  of  the  machine  tool  is  based  upon  the  product  going 
across  it? 
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COVINGTON:  Yes  it  is.  If  you  don’t  have  enough  accuracy,  then  you  can’t  produce  the  part. 

We  always  want  to  monitor  when  the  machine  starts  deteriorating.  Once  these  values  have  been 
established  for  a particular  part  type,  then  we  want  the  performance  to  remain  within  the  limits 
that  we  set.  If  the  machine  exceeds  these  values,  then  we  investigate  what  is  happening 
(workloads,  etc.). 

DAHILIG:  System  external  data  facets  are  the  things  that  we  need  from  the  system  that  we  don’t 
control:  people  associated  with  the  shops,  associated  with  the  machine.  Product  data:  eventually 
we  are  going  to  integrate  all  of  this  with  our  product  measurement  Statistical  Process  Control 
(SPC)  data. 

DONMEZ:  What  do  you  mean  by  data/machine  tool  structures? 

COVINGTON:  Defining  our  machines:  configuration,  primary  axes. 

DONMEZ:  Does  Boeing  define  the  classification?  That  is  one  of  the  things  that  I mentioned 
before  that  NIST  has  previously  done  some  work  in  this  area. 

COVINGTON:  Boeing-defined  classification  means  that  the  machine  should  conform  to 
parameters  in  machine  tool  industry. 

DAHILIG:  This  data  diagram  is  a little  bit  incomplete.  There  are  additional  one  or  two  facets, 
possibly  more.  The  one  that  I definitely  know,  which  is  not  included  in  here  yet  is  the  portion 
that  takes  care  of  the  diagnosis  recovery  information.  Also,  we  are  talking  about  integrating  with 
maintenance  system. 

KATTER:  Has  this  already  been  implemented? 

DAHILIG:  No,  we  are  in  the  process  of  implementation. 

COVINGTON:  We  recently  acquired  the  resources  to  manage  this  implementation. 

DAHILIG:  System  Definition  P+  200:  This  is  at  a high  conceptual  level  of  what  all  is  involved 
with  the  system.  These  are  subsystems  and  they  are  usually  identified  by  SSI,  SS2,  etc.. 
Everything  within  the  interior  rectangle  is  what  MCDRS  is  responsible  for.  Everything  external 
is  what  effects  MCDRS:  what  it  reads  or  writes,  from  groups  of  people  or  external  systems. 

These  rectangles  are  called  external  actors.  Quality  assurance  is  involved  here,  machine 
operators,  management,  shop  management,  maintenance,  etc.  Sub-system  1 is  where  we  manage 
the  machine  information.  Someone  has  to  identify  what  machines  are  going  to  be  statistically 
analyzed.  We  put  a performance  track  on  it.  Then  the  data  goes  into  the  system.  Of  course,  there 
is  always  visibility  of  this  information.  This  block  here  called  subject  is  called  the  data 
repository.  There  are  arrows  going  into  and  coming  out  of  the  data  repository.  The  information 
that  goes  in  is  the  manufacturing  equipment.  Sub- system  2,  manage  assessments:  that’s  the 
process  associated  with  setting  up  your  assessment  plans,  parameters,  expected  acceptable 
tolerance  ranges  for  those  assessment  plans  and  frequencies,  the  administration  of  those  plans. 
Sub-system  3 up  in  the  comer,  manage  machine  measurements:  that  is  definitely  bigger  than  the 
other  two  subsystems.  That  has  to  do  with  actually  running  the  assessment,  getting  the  data, 
getting  the  parameter  values,  getting  into  the  data  repository,  performing  quick  analysis  on  the 
data,  and  also  more  detailed  analysis  is  available.  There  is  some  immediate  feedback  between  the 
person  that  is  running  the  tests  and  then  uploading  to  the  data  repository.  Also,  if  there  is  a 
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problem  detected  with  the  tests,  then  that  will  trigger  the  problem  diagnosis  and  automatic 
notification  to  the  appropriate  management  or  person  who  should  have  visibility  if  there  is  a 
problem  with  the  machine.  Facilities  are  also  involved  for  maintenance  issues.  Sub-system  5, 
manage  the  problem  diagnosis:  that  handle  the  problems  coming  into  the  system,  diagnosis  are 
based  upon  knowledge  or  past  experience.  If  we  don’t  have  that  experience  then  we  can  build  it. 
Maintenance  can  have  input  to  the  diagnosis  of  the  problem.  Recovery  will  also  have  a 
knowledge-based  portion,  based  upon  past  experience  and  knowledge  where  we  can  determine 
the  recovery  for  a particular  type  of  problem.  We  can  also  build  that  experience  base  by 
obtaining  input  from  maintenance  or  the  machine  operator. 

DONMEZ:  What  is  the  time  frame  to  implement  these  sub-systems? 

DAHILIG:  That  is  still  to  be  determined.  Because  we  are  considering  this  system  for  an 
enterprise- level  effort,  we  are  still  setting  up  a steering  committee,  not  only  with  our  maintenance 
people,  but  we  are  trying  to  identify  those  people  who  should  be  involved.  Also,  we  are  basing 
our  development  on  a concept  on  what  I’m  calling  distributed  teaming;  distributing  our  software 
engineering.  We  are  also  doing  many  things  with  commercial  off-the-shelf  software  (COTS), 
bringing  in  software  from  outside  and  trying  not  to  develop  as  many  projects  inside.  There  is 
always  the  need  to  customize  to  our  particular  process.  We’re  expanding  not  only  to  external 
suppliers,  but  also  interior  to  Boeing.  Boeing  is  so  large  and  we  have  so  many  regions.  Like 
Marty  mentioned  we  have  brought  in  McDonnell  Douglas  and  Rockwell  and  with  all  of  their 
regions.  Across  Boeing,  we  have  many  pockets  of  activities.  The  issues  with  machine 
maintainability  and  machine  performance  and  how  do  we  use  our  machine  tools  optimally.  It  is 
not  a problem  that  only  Boeing  faces.  Everyone  in  manufacturing  experiences  these  issues 
(Factory  Computing  Architecture  that  Boeing  has)  and  is  something  we  are  all  trying  to  solve. 

All  of  these  pockets  internal  to  Boeing  are  all  trying  to  grasp  and  come  to  terms  with  this.  Based 
upon  their  focus  or  expertise,  maybe  they  created  small  systems  that  perform  something,  maybe 
for  their  particular  types  of  machines  or  tests  that  they  perform.  There  aren’t  any  systems 
presently  available  that  integrate  everything  at  a Boeing-wide  level.  That  is  what  MCDRS  is 
trying  to  accomplish  at  an  enterprise  level.  As  part  of  that  philosophy,  the  distributed  software 
engineering,  we  are  trying  to  identify  what  pockets  activity  are  out  there,  what  are  they  doing  and 
at  what  level.  We  anticipate  finding  several  small  systems  and  plan  for  their  integration,  but  we 
want  development  to  be  the  least  amount  of  resources  required  as  possible.  One  of  the  reasons  I 
am  here  is  that  I am  interested  in  what  you  at  NIST  have  to  offer.  I can  see  two  areas  where  you 
can  help  us:  (1)  analysis  tools  and  (2)  the  data  repository.  We  already  have  a data  model,  it  is 
currently  at  the  physical  level.  We  would  like  to  standardize  with  industry  and  we  think  we  can 
help  you  as  much  as  you  can  help  us.  One  of  the  main  things  that  I definitely  see  that  you  can 
help  us  with  is  the  analysis  tools. 

HEMMERLE:  How  is  this  all  funded?  Is  this  indirect  manufacturing  expense?  Do  you  have 
separate  costing  for  your  time  and  your  time  to  know  what  this  is  costing  to  determine  the 
payback? 

DAHILIG:  Yes. 

HEMMERLE:  What  type  of  annual  budget  is  that? 

COVINGTON:  I can’t  get  too  specific  on  that,  because  I also  don’t  know  too  many  details. 
However,  I can  give  you  a generalization  from  my  interpretation.  In  all  of  our  different  regions, 
as  Angel  has  indicated,  we  perceive  the  same  kinds  of  needs.  We  have  many  isolated  groups 
utilizing  their  own  overhead  money,  their  own  resources  to  provide  solutions.  We  have 
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duplication  of  effort  in  many  areas  throughout  the  company  and  even  throughout  divisions. 

We’re  trying  to  bring  together  solutions  that  will  solve  these  types  of  problems.  A handful  of 
people  from  each  region  came  together  to  integrate  the  individual  systems,  and  to  build  upon  each 
resource.  We  have  some  other  track  work  to  be  done  yet  to  make  sure  that  we  are  getting  the  type 
of  management  support  we  need  to  succeed.  This  project  has  been  around  for  a couple  of  years, 
conceptually.  The  main  thing  that  we  are  trying  to  do  is  bring  together  and  facilitate  a partnership 
to  develop  mutually  beneficial  packaged  applications.  We  don’t  have  a large  set  of  resources,  we 
have  to  use  the  existing  resources  and  learn  how  to  interact  more  efficiently  with  our  peers. 

HEMMERLE:  What  I was  looking  for  is,  are  you  able  to  get  internal  teaming:  your  key 
maintenance  specialist  that  understands  the  variance  within  the  hardware,  how  it  came  about 
within  the  machine,  or  what  the  variance  within  the  machine  track  looks  like  on  the  hardware. 

Are  you  able  to  get  those  types  of  people  many  hours  per  week  to  help  you?  Alternatively,  are 
you  going  to  outside  people  to  help  you?  Do  you  have  enough  internal  people  who  support 
current  operations  and  are  willing  to  team?  I have  a perfect  barrier  there. 

COVINGTON:  Yes  we  can.  In  my  experience,  when  you  show  what  benefit  can  be  expected, 
they  see  what  you  need  and  will  respond.  With  limited  resources  we  need  a high  level  of  support. 

HEMMERLE:  You  can  get  high  level  support,  but  I’m  talking  about  the  guy  on  the  ground  only 
has  so  many  hours  per  week  and  this  is  equipment  to  them.  How  do  you  balance  what  is 
important  to  the  manager  and  product  importance? 

COVINGTON:  We  have  the  same  problem. 

KITNA:  We  are  also  using  Factory  Computing  Architecture  Program  as  a vehicle  for  getting 
more  support  and  combining  resources. 

COVINGTON:  I’ve  been  at  Boeing  for  nearly  20  years.  I’ve  seen  a lot  of  change  in  attitude 
within  the  last  3 to  10  years.  I have  seen  redirection  toward  the  motion  for  common  processes  as 
opposed  to  the  variance  that  has  occurred  in  the  years  past,  where  people  didn’t  talk  with  anyone 
else.  We  are  in  a “better  world”  for  cooperation,  to  share  information  due  to  common 
requirements  that  we  all  have.  We  have  to  work  together  now. 

DAHILIG:  Production  has  had  “big  brother”  looking  over  their  shoulder  in  the  past  for  reduced 
productivity.  But  during  the  process  of  talking  with  them,  we  realized  that  they  haven’t  had  the 
data  to  document  what  was  going  on  with  the  machines.  Talking  with  the  different  pockets  of 
production  within  Boeing  helps  with  the  realization  that  others  could  use  this  system  to  their 
benefit  to  help  them  to  do  their  job  better.  Upper  level  management  sees  the  potential  benefit  and 
the  provides  buy  in,  but  doesn’t  force  the  system  on  anybody.  When  management  sees  a benefit 
to  their  own  organizations,  as  well  as  the  overall  company,  then  it  really  helps  to  get  the  needed 
support.  That  has  been  my  experience. 

Architecture  Strategies  for  MCDRS:  As  I have  said,  MCDRS  is  on  the  Boeing  Intranet  web. 
Because  it  may  become  an  enterprise  system,  visibility  and  access  to  the  system  development  and 
data  is  really  important.  Some  of  the  reasons  for  putting  it  on  the  web  are  because  of  the  Boeing- 
wide computing  interface  process;  to  lessen  the  importance  of  hardware  and  geographical 
constraints  and  the  advantage  is  local  data  across  regional  or  across  the  enterprise. 

Our  current  progress  as  I mentioned  is  that  we’re  in  the  preliminary  analysis  phase,  to  be 
completed  sometime  towards  the  end  of  this  year.  One  of  the  reasons  that  our  schedule  is  sliding 
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a little  is  because  of  our  increased  emphasis  on  the  “Boeing-wide”  coordination.  We  currently 
have  a conceptual,  functional  and  physical  data  model.  We  have  a conceptual  process  model. 
We’re  working  on  our  functional,  and  what  that  means  is  we’re  breaking  down  the  sub-systems 
into  functions.  The  technical  and  functional  alternative  analysis  for  our  recommendations  is  in 
progress. 

We  have  our  intranet  site  established  and  we’re  still  working  on  it  and  trying  to  get  more  input 
from  other  people  within  the  company  for  communication.  As  I mentioned  earlier,  we’re  at  level 
3 status.  Jim  will  take  over  now. 

CHANDRASEKHARAN:  You  mentioned  before  that  you  have  an  enterprise  level  issue.  Are 
you  making  your  data  accessible  across  the  business  units  and  facilities  as  well? 

COVINGTON:  Typically  regional.  There  are  some  types  of  analysis  that  can  be  used  over  a 
wider  range.  However,  regionally,  there  is  some  need  to  contain  that  information  to  some  extent. 
Technically,  you  could  share  that  information  with  other  geographical  areas. 

DAHILIG:  Our  plan  is  that  people  from  other  regions  can  access  the  information.  We  are  still 
working  on  the  security  issues  on  the  server,  the  speed,  connection  and  related  items. 

CHANDRASEKHARAN:  The  issue  is  then  not  technical,  but  sharing  too  much  information  with 
your  suppliers/customers. 

COVINGTON:  That  issue  is  more  internal.  We’re  working  hard  to  bridge  the  gaps,  with  all  of 
our  sub-business  units  if  you  will,  our  suppliers.  Sometimes  there  are  problems  that  arise 
between  business  units  and  we  try  to  make  that  information  available  on  request,  but  not 
necessarily  in  a forum  where  there  is  no  control  of  the  information.  We  don’t  want  to  have 
incorrect  conclusions  drawn  from  data  that  was  acquired  without  understanding  all  of  the 
parameters  involved.  There  is  a risk  in  making  information  totally  available,  that  people  may 
draw  incorrect  conclusions.  That  is  one  of  the  things  that  we’re  trying  to  manage  with  this 
regional  concept.  When  we  say  regional,  we  want  the  same  tools  used  throughout  Boeing, 
Wichita,  Seattle,  that  we’re  using  the  same  clones,  the  same  kinds  of  software,  the  same 
interfaces,  the  same  kinds  of  data.  The  fields  will  all  be  the  same  Boeing-wide,  there  will  be 
some  differences  and  some  amount  of  security  of  information.  To  manage  the  sensitive  areas, 
some  managers  have  had  problems  sharing  certain  types  of  information.  We’re  still  exploring 
these  issues.  I personally  believe  in  wide-open  information,  where  it  is  not  competitive  or 
sensitive,  but  at  the  same  time,  there  are  certain  political  aspects  as  well. 

DAHILIG:  There  are  some  functional  issues  as  well  as  technical  that  need  to  be  worked  out. 

COVINGTON:  We  have  a communications  project,  a graphical  tool  that  we  have  just  started. 

We  put  all  the  relevant  information  on  the  Intranet  and  made  it  available  to  anyone  in  Boeing. 
Essentially,  the  documentation,  ballbar,  our  teaming  efforts,  project  status,  all  of  the  different 
facets  of  what  we’re  doing  are  being  communicated  with  our  team  members  within  Boeing 
through  this  tool. 

Right  now,  we  have  laptops  out  on  the  shop  floors.  We  are  running  lasers  and  ballbars,  all  kinds 
of  different  tests  and  equipment.  By  and  large  we  have  a lot  of  different  types  of  information  that 
is  taken  on  site  and  at  the  machine  that  is  not  being  captured,  contained,  or  compared  to  previous 
history.  The  laptop  moves  and  we  don’t  have  a centralized  database.  We  are  collecting  data  and 
what  I hope  to  have  happen  is  that  we  establish  configuration  management,  so  when  data  is  taken 


15 


with  a laptop  or  whatever  system  that  they  have,  the  set  of  information  that  is  captured  is 
consistent.  This  information  is  taken  by  a variety  of  people.  The  laser  work  that  we  have  done  is 
always  performed  by  maintenance  or  Quality  Assurance.  We  have  some  limited  activity 
performed  by  the  operator,  (i.e.,  ballbar,  certain  types  of  spindle  analysis,  etc.)  simple  tests  to  get 
a quick  feel  of  how  that  system  is  performing.  From  that  information,  we  get  a simple  stoplight 
analysis  chart  that  shows  performance  over  time  for  any  of  these  types  of  tests.  The  system 
responds  with  a “red”,  “yellow”,  or  “green”  light  to  inform  the  operator  of  the  condition.  This 
information  is  fed  back  into  the  database,  compared  to  previous  information  and  certain  types  of 
analysis  are  performed  so  that  we  can  see  any  types  of  trends  developing  and  any  other  things  that 
are  happening  that  we  need  to  be  alerted  to.  From  that,  we  are  using  Microsoft  Exchange  to  email 
out  different  kinds  of  messages  (signals),  for  one  thing,  the  schedule  notification.  We  had  a real 
problem  with  accountability.  We  have  many  systems,  we  don’t  run  them  as  often  as  we  say 
we’re  going  to  run  them,  therefore  we  need  to  manage  the  schedule  so  that  we  know  whether  or 
not  certain  tests  were  run.  If  a test  comes  back  with  errors  associated  with  it,  then  we 
automatically  send  another  signal  that  notifies  management.  Quality  Assurance  and  others  as 
required.  Schedule  notification  in  relation  to  maintenance:  sometimes  we  have  a difficult  time 
performing  the  tests  around  the  production  schedules  that  we  have  set  for  ourselves  and  we  need 
to  be  aware  of  those  things.  This  is  kind  of  an  overall  view,  using  messaging,  to  track  the  overall 
performance  of  the  machines.  This  is  just  for  machine  capability  and  not  for  the  measurements  of 
production  parts.  You  can,  in  parallel,  compare  the  machine  performance  data  with  your  part 
measurement  data.  Our  ultimate  goal  is  to  be  able  to  predict  part  performance  by  tracking 
machine  performance,  that  you  can  control  the  resulting  part  by  controlling  the  parameters  of  the 
machine  process. 

Capture  database  knowledge  and  make  decisions:  this  is  a teaming  effort,  operators,  metrology, 
maintenance,  all  of  the  personnel  necessary,  including  a group  like  this  NAMT  workshop  to  help 
us  understand  the  problem,  what  the  theory  is  and  help  us  utilize  it  to  make  decisions.  We  are 
back  to  decisions;  we  need  to  make  decisions  that  are  based  on  solid  information. 

We  put  together  a simple  database.  It  consists  of  the  actual  reference  information,  type  of 
machine,  table  size,  location,  travels  and  those  types  of  things.  For  example,  the  21  machine 
error  parameters  of  a machine,  roll,  pitch,  yaw,  etc.  What  I’d  like  to  do,  we’re  not  there  yet,  is  to 
click  on  these  error  parameters  and  not  just  see  the  values,  but  the  ability  to  see  the  charts.  One  of 
my  goals,  I’m  sure  we’re  going  to  see  a little  of  it  with  the  ballbar,  is  to  see  similar  types  of 
analysis  for  the  other  types  of  tests.  I hope  we  would  see  these  values  for  a certain  machine  and 
that  we  can  compare  different  time  intervals  simultaneously  to  see  the  trends  for  machines.  In 
one  case  you  may  have  linear  accuracy  for  an  axis  and  can  look  at  a chart  to  see  what  is  going  on 
at  a particular  location.  We  identify  zones  of  the  machine,  some,  which  are  acceptable,  and 
others,  which  are  not.  We  do  that,  but  we  want  a system  to  allow  for  management  of  the 
information  in  a more  systematic  manner. 

The  ballbar  is  one  test  that  is  quick  and  dirty  that  gets  our  operators  involved.  It  is  a quick 
indicator  and  that  is  the  only  reason  we  use  it.  I caution  everyone,  if  you  really  want  to  know 
what  is  going  on,  use  a laser  system.  Some  of  the  process  controls  we  provide  include  pictures  so 
that  the  operators  will  have  a visual  reference  for  the  setup. 

We  can  produce  graphical  outputs  using  DOS-based  software,  which  doesn’t  lend  itself  to  the 
working  environments  that  we’d  like. 

We  also  have  another  analysis  tool  for  the  operators  to  look  at.  We  created  software  around  one 
of  the  Renishaw  products.  What  Renishaw  doesn’t  do  very  well  is  keep  track  of  your  machines. 
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operators,  and  certain  kinds  structure  that  we  need  to  monitor  our  business  units.  Ours  is  just  a 
simple  monitoring  system.  We  did  actually  detect  a problem  that  was  occurring  in  all  three 
planes  of  a machine  with  this  system. 

We  generate  charts  trending  across  the  three  primary  machine  planes.  All  of  these  machines  have 
different  ages,  histories,  and  those  kinds  of  things.  One  of  these  machines  has  a serious  problem 
in  the  XY  plane. 

CHANDRASEKHARAN:  You  mentioned  having  software  that  is  wrapped  around  the  Renishaw 
product.  Is  their  package  running  in  the  background  and  you  are  just  working  around  their 
package? 

COVINGTON:  Yes.  We  just  built  an  interface  to  their  package  and  didn’t  reinvent  anything 
produced  in  their  package. 

CHANDRASEKHARAN:  Do  you  take  the  Renishaw  (.rtb)  files  stored  and  then  analyze  or  is  it  a 
real  time  operation? 

COVINGTON:  We  set  up  all  of  the  parameters,  manage  the  .rtb  files  and  have  template  files, 
which  we  use  over  and  over  and  always  have  the  same  set.  We  have  configuration  control  over 
the  setup  this  way,  so  that  two  different  operators  will  collect  the  data  the  same  way.  We  also 
manage  to  store  the  data  associated  with  a particular  machine  with  the  time  and  data  filenames; 
all  of  the  data  is  managed.  That  is  what  I mean  by  a front  end,  not  really  a database,  but  manages 
information.  We  have  one  ballbar  system  per  shop.  Our  system  allows  the  operator  to  pick 
which  machine  to  test;  the  software  manages  the  files  and  places  information  in  the  right  places 
for  analysis.  We  also  produce  extra  charts,  for  comparison. 

DEFORGE:  I visited  some  of  the  facilities  at  Boeing.  They  are  using  a simulation  of  job  setup. 
In  Seattle  they  are  looking  at  modeling  about  1 70  machine  tools  and  I noticed  that  you  had  your 
links  to  try  to  show  the  machine  tool  itself.  It  would  be  interesting  to  draw  on  those  resources  of 
setup  and  modeling  and  bring  them  together  on  your  web  page  so  you  can  go  to  your  machine,  go 
through  a step-by-step  description  of  the  job  setup. 

COVINGTON:  I didn’t  show  you  that  but  it  is  a rather  lengthy  process  to  setup.  We  have  setup 
instructions  that  are  customized  for  a particular  machine.  You  have  an  excellent  idea  to  have  the 
pictures  available  during  the  setup,  and  we  do  that  with  our  system. 

DEFORGE:  A 3-D  model  for  that  type  of  situation  is  beneficial  because  you  can  pan  to  different 
views  and  angles  of  the  setup.  Talk  with  Joe  Analy  down  in  St.  Louis,  I can  give  you  a name  and 
number  to  do  that.  A window  will  come  up  with  a 3-D  view,  which  works  similar  to  a tape 
machine  in  that  you  just  hit  play,  and  it  is  different  in  that  once  you  start  to  play  you  can  use  your 
mouse  to  move  around  at  will.  Then  a set  of  instructions  comes  up. 

COVINGTON:  We’re  working  in  some  cases  with  386  computers  and  I’m  concerned  about 
getting  too  high  tech.  That  is  an  excellent  suggestion  for  us  to  look  at. 

SOONS:  To  follow  up  on  the  second  issue,  an  important  component  for  the  comparison  of 
machines  to  work  is  that  you  also  have  to  standardize  setups,  standardize  ways  to  measure 
machines,  and  standardize  what  kind  of  tests  you  are  going  to  do  on  the  machines.  Is  that  an 
important  part  of  your  overall  scheme,  to  standardize  these  issues?  My  second  question  is,  do 
you  use  tests  during  production? 
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COVINGTON:  The  answer  to  the  first  question  is  absolutely  we  need  to  have  standard  tests,  like 
tests  for  like  machines.  If  we  use  a machine  for  certain  purposes  and  you  know  what  its  defining 
qualities  are,  then  you  should  use  the  same  tests  on  those  machines,  run  in  exactly  the  same  way. 
Then  we  look  at  performance,  how  much  deterioration  do  we  see  over  time  to  determine  at  what 
frequency  interval  we  should  measure  the  machine.  The  answer  to  the  second  question  is  a 
qualified  yes.  One  of  the  biggest  problems  in  the  maintenance  world  is  that  the  shop  often  won’t 
give  up  the  machine,  they’ll  run  a machine  into  the  ground.  What  we  want  to  make  sure  happens 
is  that  when  an  agreement  with  the  shop  and  the  shop  management  is  made  about  the 
methodology  of  performing  a test,  we  want  to  make  sure  the  agreements  are  fulfilled,  and  this 
messaging  system  helps  us  do  that.  Yes  there  are  going  to  be  problems,  and  yes  we  are  not  going 
to  want  to  stop  production  to  make  measurements.  In  the  past  we’ve  had  unscheduled 
breakdowns  and  part  scrappage  that  scheduled  maintenance  might  have  prevented.  What  we’re 
working  on  is  that  these  machine  measurements  become  scheduled  events. 

HEMMERLE:  My  different  machines  have  different  mean  accuracy  work  zones.  Sometimes  it 
may  be  500  mm  high;  sometimes  it  may  be  200  mm  high.  My  systems  people  want  me  to  run  the 
same  test  in  the  same  spot,  yet  my  accuracy  is  in  a different  place.  You  can’t  really  perform  the 
test  and  get  the  comparison  that  you  want.  If  we’re  in  agreement,  then  you  need  to  go  talk  to  my 
quality  people. 

COVINGTON:  You  have  to  determine  in  what  zones  you  are  going  to  run  your  test.  You  may 
have  to  run  multiple  tests  to  get  the  information  that  you  want.  Where  you  make  the  test  is  part  of 
your  test  definition.  It  varies  from  machine  to  machine.  We  would  like  to  make  it  as  similar  as 
possible,  but  sometimes  performance  requirements  and  other  issues  make  life  complicated. 

To  recap,  what  we  are  trying  to  do  is  to  control  the  resulting  part  by  controlling  the  process.  We 
want  to  assure  our  process  is  performing  adequately.  In  the  past,  we  just  relied  on  faith  until 
machines  broke  down.  We  are  now  monitoring  the  performance  of  machines  to  prevent 
breakdowns.  We  are  trying  to  maintain  performance  data  adequately.  We  are  implementing 
accountability,  machine  performance  report  cards.  We  want  to  discover  new  ways  of  measuring 
machines,  to  understand  and  optimize  the  methodology  and  report  on  machine  data. 

DEFORGE:  If  you  were  to  link  this  data  that  you  are  collecting  on  machine  tools  back  to 
simulation  models  that  you  are  doing  on  process  prove  out  and  things  of  that  nature,  would  you 
primarily  be  looking  to  identify  inaccurate  zones  on  your  machine,  to  flag  the  operator  to  not  use 
certain  work  zones?  Alternatively,  are  you  looking  for  and  actual  reflection  of  the  inaccuracies  on 
the  generation  of  the  part? 

COVINGTON:  I don’t  think  you  ever  want  to  change  your  model.  The  model  needs  to  stay  pure 
no  matter  what.  One  of  the  problems  that  we  had  until  recently  is  that  even  if  you  knew  the 
geometry  of  the  machine,  you  didn’t  know  on  which  machine  a particular  part  was  going  to  be 
manufactured.  Now  we  can  target  our  products  for  a particular  machine  for  a particular  accuracy. 
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Machine  Tool  Management  and  Machining  Simulation 
Vivek  Chandrasekharan 
Caterpillar,  Inc. 


Jim  Katter  is  with  me  and  we  work  on  machine  tool  management  and  machining  simulation.  My 
presentation  is  focused  more  on  the  specifics  of  our  project  and  not  as  much  on  the  high  level  as 
what  we’ve  been  hearing  today. 

Our  focus  continues  to  be  in  three  main  areas:  (1)  process  planning,  (2)  machine  performance 
data  and  asset  management,  and  (3)  simulation.  [Slide  3-2].  I’m  specifically  going  to  talk  about 
three  or  four  areas  of  progress  that  we’ve  made  since  we  last  met  in  February.  We’ve  had 
increased  pressure  from  plant  to  implement  “something”.  That  is  as  much  definition  as  you  get 
from  plant.  “We  want  something  and  we  want  it  now  and  it  is  your  job  to  get  it  done”.  We’ve 
actually  leveraged  a lot  from  this  community,  from  the  work  that  NIST  has  been  doing. 

Therefore,  we  really  appreciate  that.  We  did  sign  the  NIST  CRADA.  I will  talk  more  about 
some  collaborative  work  that  we’ve  been  doing  there  as  well. 

First,  I would  like  to  talk  about  machine  classification.  [Slide  3-3].  We  leveraged  the  work  of 
NIST  published  in  the  document  - NISTIR  5707.  We  actually  took  that  and  implemented  it  by 
taking  several  machines  and  putting  data  into  the  classification.  It  worked  really  well  and  we’re 
happy.  There  were  a few  changes  the  plants  wanted.  They  wanted  information  on  work  area 
issues  that  are  relevant  to  our  planners  such  as  the  maximum  capacity  of  a hoist  or  a lifting  device 
etc.  There  was  some  information  that  was  very  specific  to  the  way  we  do  business,  so  we  merged 
it  with  our  internal  “machine  folders”,  which  is  a folder  that  process  planners  keep  and  it  varies 
from  one  business  unit  to  another.  We  combined  some  of  that  information  with  what  NIST  had 
and  implemented  “something”.  There  are  several  issues  with  platform  of  implementation  and 
layering  that  we  talked  about  earlier  that  are  yet  to  be  addressed.  We  also  want  to  make 
additional  high  level  information  accessible  to  the  plants  so  managers  can  plan  capacity  related 
issues.  There  also  has  to  be  link  to  commercial  databases  for  new  machines  such  as  the  Machine 
Selector  software.  We  have  not  got  to  those  details  yet.  The  good  news  is  that  the  machine 
classification  that  NIST  had  and  some  of  the  things  that  Hans  Soons  presented  at  a previous 
meeting  merged  really  well  when  we  implemented  them. 

There  are  issues  that  have  come  up  in  the  repository  as  to  what  kind  of  errors  we  store  and  how 
the  errors  are  characterized.  [Slide  3-4]  We  heard  a lot  about  the  ballbar  and  the  laser,  there  is 
work  that  universities  addressing,  issues  of  thermal  errors  and  ambient  effects,  repeatability  and 
combining  all  these  errors.  We  eventually  want  to  know  how  all  of  these  effect  the  part.  As  a 
start,  we  tried  comparing  laser  data  with  ballbar.  We  tried  to  take  quasi-static  errors  from  laser 
data  models  and  injected  them  to  a circular  path,  to  see  if  it  compared  with  the  ballbar  data.  It 
was  not  that  close.  We  haven’t  had  much  success  yet,  because  there  are  other  errors  that  the 
ballbar  picks  up  such  as  servo  mismatches  and  backlash,  etc.  that  you  don’t  capture  with  the  laser. 
Some  of  the  differences  could  be  in  the  way  that  we  are  simulating  the  system.  We  are  still 
debugging  that  portion.  It  is  very  interesting  to  try  to  understand  how  these  errors  can  actually 
combine. 

There  is  internal  work  that  we  are  doing  in  the  simulation  area  in  validating  the  data  model  for  the 
machine  classification.  [Slide  3-5].  We  have  more  experience  with  machine  characterization 
using  different  tools  such  as  the  API  5-D  laser.  Standardization  issues  as  you  mentioned  about 
the  ballbar  tests,  how  different  people  might  do  things  and  how  to  address  those  issues.  We 
learned  a lot  more  there  and  a lot  more  about  how  our  work  relates  to  the  repository  as  well. 
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We’ve  done  some  work  in  the  quasi-static  machine  error  measurement  and  simulation.  We  came 
up  with  a file  format  for  machine  errors  that  you  get  from  tests,  and  we  used  a neutral  file  format 
to  represent  these  errors.  This  is  as  an  interim  solution.  We  define  the  coordinates  that  are 
measured,  minimum  and  maximum,  and  also  what  is  the  zone,  how  to  store  the  variables,  the 
coefficients  of  a polynomial  fit,  so  we’re  not  storing  the  raw  data.  This  is  something  that  has 
worked  well,  but  it  needs  to  be  tested  a lot  more  and  validated  with  different  kinds  of  errors  that 
you  might  store.  It  is  less  data  intensive. 

Specific  to  the  NIST  repository,  we  were  successful  in  submitting  a ballbar  data  set.  [Slide  3-6]. 
Larry  Welsch  walked  me  through  one,  and  it  worked  great  the  first  time.  We  took  a Renishaw 
ballbar  output  and  submitted  the  data.  We  did  some  comparative  analysis  with  the  reports  that 
Hans  Soons  has  generated.  I believe  he  was  using  the  ISO  230-5  format.  I’ll  show  you  some  of 
the  plots.  I used  some  of  Hans’  data  definitions.  We  have  been  working  with  Larry  on 
communication  and  demonstration  issues  as  well.  No  major  breakthroughs  since  the  firewall  is  in 
the  way. 

At  this  time,  I will  show  you  the  data  we  submitted  to  NIST.  [Slide  3-7].  This  was  the  ballbar 
data  that  we  took  for  the  machine  and  you  are  familiar  with  the  Renishaw  output  so  I will  not 
show  those.  However,  I will  show  you  the  ISO  230-5  output,  you  can  see  the  min/max  numbers 
that  are  output.  This  is  the  report  that  is  generated  in  the  NIST  repository  and  these  are  the 
numbers.  [Slide  3-8].  However,  we  need  to  move  on  and  that  will  be  the  focus  of  my  talk.  We 
need  to  understand  the  algorithms  to  reduce  the  data,  errors  that  are  output  from  the  Reshishaw, 
squareness  and  other  types  of  errors.  This  may  not  be  new  to  you,  we  came  across  some  work  at 
Tempre  University  of  Technology  at  Finland,  where  they  have  developed  algorithms  and 
software  that  takes  ballbar  data  from  different  instruments,  Renishaw  and  some  of  the  others,  and 
computes  errors  similar  to  what  Renishaw  outputs.  [Slide  3-9].  That  could  be  something  that  we 
potentially  look  at  to  develop  a standard. 

CHANDRASEKHARAN : Someone  mentioned  how  to  go  in  and  find  acceptable  limits  of 
machines.  [Slide  3-10].  You  can  go  in  and  change  the  errors  in  each  of  the  backlash,  squareness, 
pitch,  and  scale  errors  and  then  the  software  will  re-plot  and  show  how  the  errors  effect  the  test. 
[Slide  3-11].  I think  it  could  help  US  industry  to  apply  some  of  this  and  maybe  standardize  some 
of  the  algorithms  for  data  reduction.  What  happens  is,  when  we  talk  about  measuring  Machine  A 
and  Machine  B with  two  different  ballbars  and  all  you  track  are  the  final  numbers,  then  you  are 
not  going  to  be  comparing  the  same  two  squareness  numbers;  you  are  not  comparing  the  same 
two  performance  capabilities  of  the  machines.  We  would  be  very  interested  in  understanding  the 
algorithms  for  correctness  and  how  accurate  they  are.  I don’t  know  if  it  is  public  domain  and 
accessible  to  us.  I would  like  to  move  in  that  direction.  It  is  a shareware  right  now  and  they  gave 
it  to  us  with  a timed  license.  It  is  a windows-based  program  where  they  just  gave  us  the 
executables  and  no  source  code;  fairly  user-friendly.  I also  compared  the  different  errors.  You 
can  see  that  many  of  them  are  close  to  what  Renishaw  comes  up  with,  it  depends  on  the  numbers. 
Renishaw  tends  to  report  the  average  numbers,  you  can  see  they  report  some  in  the  clockwise  and 
others  in  the  counterclockwise  directions,  and  some  of  the  axes  backlash  numbers.  But  the 
numbers  are  very  close,  so  the  algorithms  that  they  have  developed  appear  to  be  the  same  as 
those,  which  are  used  by  Renishaw  and  other  programs.  If  this  is  public  domain  type  of 
knowledge,  then  we  would  like  to  start  working  with  it  in  the  B5  or  an  appropriate  committee  to 
try  to  drive  those  to  a standard,  so  we  can  at  least  make  comparisons. 

Now  I’d  like  to  address  what  we  want  to  come  out  in  the  near  future  and  what  we’d  like  to 
contribute  to  the  road  map.  [Slide  3-12].  First,  standardizing  the  method  of  computing  the  errors, 
we  can  keep  tracking  that.  In  the  ballbar  area,  we’d  like  to  see  in  the  repository  is  comparative 
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analysis  of  machines.  I think,  talking  with  Hans  and  Larry  that  they  intend  to  have  the  capability 
of  overlaying  plots  and  also  trending  data.  We’d  like  to  understand  how  this  is  performed. 
Another  essential  issue  is  that  we  want  to  work  with  our  suppliers,  whether  it  is  machine  builders, 
or  suppliers  of  this  technology,  so  that  we  can  standardize  formats.  We’ve  worked  with  the 
Renishaw  format,  but  there  are  obviously  others.  We  want  to  work  on  getting  this  technology 
transferred  to  us.  We  want  to  keep  working  in  parallel  in  acquiring  some  of  the  code.  We  want 
to  work  on  performing  a demonstration  of  doing  some  corrective  work.  The  laser  area  is  what  we 
think  should  be  the  next  logical  step.  [Slide  3-13].  We’ve  been  working  more  with  the  5-D  laser, 
but  I’m  sure  that  other  people  have  other  types  of  data  sets  (i.e.,  HP,  etc.).  I don’t  know  how  we, 
as  a group,  are  going  to  work  collectively  as  far  as  writing  interfaces  and  things  like  that.  We’ve 
come  up  with  a file  format  that  we  can  use  for  simulation  purposes,  and  we  are  developing  some 
tools  there.  We  can  either  change  to  whatever  file  format  you  come  up  with,  or  we  can  write 
interfaces  to  whatever  the  repository  comes  up  with  as  a standard.  Our  goal  is  to  take  data  that  is 
in  the  repository  and  run  simulations  to  see  how  the  machine  errors  effect  the  part.  Alternatively, 
if  our  manufacturing  produces  machine  tool  error  data,  we  want  to  see  the  simulation  of  the 
resulting  part.  In  that  context,  we  are  going  to  spend  quite  a bit  of  time  on  visualization  tools.  I 
have  a plot  to  show  what  the  machine  errors  do  to  a part.  We  plot  both  the  ideal  geometry  of 
what  you  would  like  to  create,  and  what  the  machine  errors  are  doing  to  the  part.  You  can  see  the 
amount  of  error  on  a part  feature  resulting  from  the  machine  errors.  If  you  know  that  these  are 
your  high  points,  then  you  can  start  controlling  your  process.  We  don’t  perform  any  type  of 
sensitivity  analysis  to  figure  out  which  of  the  machine  errors  are  contributing  to  these  part  errors. 
That  is  something  that  we’d  like  to  do.  But  you  can  play  with  the  numbers.  For  example,  you 
want  to  reduce  your  squareness  from  20  arc-sec  to  10  arc-sec,  then  you  can  see  what  this  does  to 
my  flatness  values.  This  gives  you  an  idea  of  how  to  correct  the  machine.  If  I have  to  maintain  a 
certain  quality  of  part  going  out  on  this  machine,  I just  need  to  bring  the  squareness  down  by  X or 
bring  the  straightness  errors  down  to  Y.  So  we  are  trying  to  use  simulation  tools,  and  I think  that 
is  what  Alkan  Donmez  has  been  trying  to  focus  on.  Trying  to  use  simulation  tools  to  drive  how 
you  want  the  machine  capabilities  defined  and  how  to  visualize  data  as  well.  We  are  very 
interested  in  this  area.  It  was  interesting  to  figure  out  how  much  error  was  coming  from  the 
machine.  I am  interested  to  see  what  Joe  Falco  has  in  his  demonstration  of  the  Deneb  software 
visualization. 

DONMEZ:  Does  this  plot  show  all  2 1 errors? 

CHANDRA SEKHARAN:  Yes.  The  machine  was  characterized  with  the  5-D  laser.  We  took  the 
output  file  and  stored  in  our  file  format.  We  used  MATLAB  to  make  a 3-D  plot  of  the  data.  We 
are  developing  capability  to  use  other  tools  for  visualization.  I know  that  API  is  developing 
visualization  tools  and  Joe  has  developed  an  interface  with  Deneb.  We’ve  shown  limitations  with 
the  IntelliCad  3-D  software  engine.  This  is  what  we’ve  come  up  with  so  far.  It  gives  you  a 3-D 
visualization  of  the  errors  and  the  opportunity  to  see  which  errors  effect  your  part  the  most.  I 
mentioned  that  we  had  a file  format  which  we  convert  the  5-D  laser  data  into,  then  that  goes  into 
the  simulation.  We  currently  do  not  store  the  raw  data,  just  model  coefficients.  It  is  not  a 
standardized  model,  but  we  can  interface  with  any  type  of  a model  that  you  create  with  your  5-D 
laser.  If  the  repository  chooses  to  store  the  raw  data,  which  seems  to  make  sense  for  the  longer 
term,  we  can  adapt  to  that.  If  the  repository  chooses  to  store  coefficients,  then  we  need  to 
standardize  a model.  We  are  not  storing  the  goodness  of  fit.  You  may  have  outliers  with  the 
model  that  you  use.  The  other  issue  is  repeatability  of  the  5-D  measurements,  the  forward  and 
reverse  data  that  is  collected.  We  perform  the  measurement  three  times  and  then  average  the 
result.  We  need  to  address  repeatability  because  that  will  effect  the  Cpk  numbers. 
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The  last  area  of  recommendation  that  we  are  interested  in  for  near  term  future  work  is  the 
simulation  area.  [Slide  3-14].  We  talked  about  the  ballbar  and  the  5-D  laser  system.  As  I 
mentioned  before  we  are  trying  to  understand  the  different  types  of  errors  (i.e.,  spindle  analyzer 
data,  tool  change  repeatability  data,  quasi-static  errors,  and  ballbar  data)  and  combine  them  for 
simulation.  If  you  want  to  simulate  a circular  path,  then  you  can  just  use  the  ballbar 
measurements.  We  are  simulating  the  quasi-static  errors,  but  if  there  are  machine  motions  that 
have  backlash  errors,  that  have  scale  mismatches,  it  is  not  necessarily  captured  with  one  test.  We 
know  that  there  are  limitations  to  just  simulating  the  quasi-static  errors.  We  want  to  determine 
how  to  combine  different  types  of  errors.  Then  there  is  the  issue  of  the  internal  representation, 
there  is  no  standard  on  the  CAD  side.  I think  that  we  could  get  some  assistance  from  this 
community  on  visualization  tools.  We  are  interested  in  sensitivity  analysis  for  machine 
correction.  We  just  have  a brute  force  method  where  we  change  parameters  and  see  the  result  on 
the  part.  I think  a more  elegant  way  is  to  do  some  sensitivity  studies.  I know  Boeing  mentioned 
that  they  wanted  to  use  knowledge-based  systems  and  methods  to  predict  part  errors. 
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Precision  Metrology 
Sean  Olson 

Automated  Precision,  Inc. 


I will  talk  about  two  projects  that  API  is  currently  working  on.  In  case  you  don’t  know,  API  is  a 
manufacturer  of  precision  metrology,  but  is  also  involved  with  using  this  equipment  in  the  field. 
We  have  3 main  systems:  5-D  laser,  ballbar,  and  spindle  analysis  systems.  These  systems 
acquire  data,  which  reflect  specific  geometric,  dynamic,  and  thermal  characteristics  of  the 
machine  tool.  Feedback  from  customers  have  led  us  to  determine  that  the  users’  in  the  field  have 
become  inundated  with  these  types  of  measurements  and  they  have  a hard  time  of  putting  the  data 
into  a manageable  form.  To  respond  to  this  need,  API  has  developed  a Microsoft  Access-based 
data  management  system  that  is  specifically  designed  to  organize  data  produced  by  our  standard 
series  of  metrology  systems.  This  database  can  handle  measurement  results  from  seven  systems 
which  include  the  autocollimator,  telescopic  ballbar,  hysteresis  system,  5-D  laser,  spindle 
thermal,  spindle  dynamic  and  electronic  level  systems.  Next  I’ll  show  some  data  from  the  5-D 
system. 

What  this  slide  is  showing  is  a typical  setup  of  what  our  5-D  laser  system  on  a vertical-milling 
machine.  [Slide  4-1].  What  we’re  measuring  here  is  the  linear  displacement  accuracy,  the 
horizontal  and  vertical  straightness  deviations  and  the  yaw  and  pitch  deviations. 

This  plot  shows  some  results  of  the  linear  portion  of  the  test.  [Slide  4-2].  This  is  error  vs. 
nominal  position  in  terms  of  machine  coordinates. 

This  plot  shows  some  results  of  the  straightness  portion  of  the  test.  [Slide  4-3].  The  top  plot 
showing  the  relative  horizontal  straightness  deviations  and  the  bottom  plot  showing  vertical 
deviations  in  terms  of  error  vs.  nominal  position. 

These  are  some  results  from  the  angular  deviations.  [Slide  4-4].  The  top  portion  indicates  yaw 
deviation,  the  bottom  pitch  deviations. 

For  a single  axis  test,  the  5-D  laser  system  produces  3 error  files  that,  in  effect,  summarize  those 
results  from  the  5 individual  measurements  that  I just  showed.  [Slide  4-5].  These  error  files  are 
just  ASCII  (American  Standard  Code  for  Information  Interchange)  text.  Currently,  we  are  just 
summarizing,  so  we  are  primarily  interested  in  maximum  error,  maximum  reversal  error,  bi- 
directional repeatability,  and  certain  parameters  that  reflect  the  mission  of  the  test:  where  you 
tested  on  the  machine,  the  length  of  the  test  that  was  performed.  This  is  the  actual  information 
that  is  read  into  the  database  management  system. 

The  system  is  designed  on  a machine  tool  basis  where  every  particular  machine  tool  you  have  a 
variety  of  tests  [Slide  4-6].  There  are  three  basic  sections.  The  first  section  deals  with  displaying 
and  previewing  certain  types  of  report  formats,  specifically  in  summaries  of  a particular  test  or 
printout  of  a history  of  performance  of  a machine  tool  for  a particular  type  of  measurement.  For 
example,  you  may  be  interested  in  certain  performance  characteristics  over  a period  of  time.  The 
second  part  deals  primarily  with  updating  and  adding  machine  tools  and  adding  individual  error 
files  for  each  particular  machine  tool.  The  third  section  deals  with  some  raw  file  management 
where  you  can  add  new  machine  tool  specifications  or  delete  a machine  tool  altogether. 

This  next  slide  is  an  example  of  the  kind  of  generic  report  format  that  the  system  currently 
outputs  where  we  are  summarizing  the  test  results  of  the  5-D  laser  system.  [Slide  4-7].  Again, 
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you  have  all  the  important  numbers  that  you  are  interested  in:  the  maximum  errors,  repeatability, 
and  backlash  types  of  errors  for  each  test. 

This  is  the  database  system  as  it  currently  stands.  It  allows  the  metrology  technician  to  manage 
the  large  quantities  of  data  that  are  being  produced  by  just  a few  simple  tools.  It  also  allows  other 
people  to  view  the  data  as  whole  or  just  pieces  of  the  data  (i.e.,  people  in  maintenance,  quality 
control,  or  production  planning).  The  future  enhancements  of  this  software  depend  upon 
feedback  from  groups,  such  as  this,  and  primarily  from  customers  in  the  field.  Currently  the 
software  is  being  tested  at  a beta  site,  where  they  have  a whole  series  of  our  equipment. 

Feedback  from  them  will  help  determine  the  specific  formats  that  they  would  like  to  see  in 
upcoming  versions.  Perhaps  the  addition  of  graphical  numerical  analysis  tools  will  be  made. 

DONMEZ:  Does  the  database  management  system  currently  only  import  API-generated  data? 

OLSON:  Currently  yes.  Eventually  we  may  be  able  to  accommodate  other  instruments. 

The  second  project  that  I will  talk  about  is  the  ongoing  development  of  a 3-D  machine  tool  error 
modeling  system.  Again,  because  of  the  high  volume  and  the  complexity  of  the  data  collected  for 
a single  machine  tool,  more  sophisticated  means  of  displaying  errors  is  required;  more  than  just 
disconnected  X-Y  plots  as  I previously  showed.  Taking  that  approach  a step  further,  we  realized 
that  the  end  user  is  ultimately  interested  in  what  part  errors  produced  from  the  machine  errors. 

API  is  currently  working  on  a Small  Business  Innovation  Research  (SBIR)  project  to  develop  a 3- 
D machine  tool  error  modeling  system  that  simulates  the  machining  process,  account  for  the 
known  measured  errors.  Eventually,  displaying  the  actual  part  with  its  associated  geometrical 
errors.  The  first  model  we  developed  was  a 2-D  model,  based  upon  data  collected  from  a CNC 
turning  center.  Using  the  2-D  model  and  assuming  a simple  nominal  part  and  process  definition, 
the  actual  tool  path  is  then  calculated.  Using  this  information,  software  was  developed  with  a 
solid  modeling  kernel  to  display  the  finished  part  with  its  associated  errors.  For  the  2-D  model, 
the  nominal  part  was  defined  as  a simple  cylinder  with  a fixed  radius  and  a simple  tool  path  on 
the  perimeter  was  assumed.  This  plot  shows  the  errors  for  the  measured  lathe  and  the  display  is 
in  error  terms  that  were  based  loosely  on  geometric  dimensioning  and  quality  principles.  [Slide  4- 
8].  For  this  particular  case,  we  show  the  radial  error  and  the  axial  error.  This  is  an  actual  solid 
modeler,  which  gives  us  the  capability  to  rotate  and  look  at  different  directions.  Further  efforts 
will  include  the  development  of  a 3-D  model  based  upon  collected  data  from  a 3 axis  CNC 
machining  center  and  the  addition  to  visualization  software  of  the  results  of  that  model.  This 
work  will  be  done  assuming  a simple  cube  for  the  nominal  part  [Slide  4-9]. 

Based  upon  the  data  from  the  3 axis-machining  center,  we  would  then  display  the  distorted  cube 
due  to  the  machine  tool  errors.  [Slide  4-10]. 

DONMEZ:  What  types  of  data  are  you  using  to  do  the  modeling?  And  is  the  data  in  polynomial 
form? 

OLSON:  Right  now,  we  are  just  using  geometrical  data,  measured  by  the  5-D  laser  for  modeling. 
The  model  is  being  developed  in  two  sections.  The  section  that  actually  crunches  the  data  is  very 
similar  to  what  was  shown  in  Vivek’s  presentation  where  all  21  errors  were  used  to  develop  the 
model,  which  displayed  the  actual  location  of  the  tool  tip  as  well  as  the  nominal  location. 
Assuming  a linear  relationship  between  points,  then  we  can  calculate  an  actual  tool  path. 
Eventually  it  will  be  combined  with  thermal  models.  Eventually  the  3-D  model  will  display  a 
cube  similar  to  the  one  shown  here,  but  distorted  due  to  the  machine  errors.  This  particular  model 
is  somewhat  abstract  because  the  process  definition  is  not  an  actual  part,  it  is  a cube  defined 
somewhere  in  the  machine  workspace.  Currently  we  are  not  programming  the  capability  of 
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simulating  an  actual  tool  path.  In  the  2-D  model  we  assume  a simple  tool  path.  For  the  3-D 
simulation,  it  will  correspond  to  a number  of  passes  over  a plane  by  an  infinitely  small  end  mill  to 
generate  that  type  of  topology.  Those  types  of  capabilities  where  we  will  be  able  to  simulate 
more  complicated  parts  will  eventually  be  incorporated. 

Now  with  software  such  as  this,  we  hope  that  we  can  give  engineers  a tool  to  implement  the 
closed  loop  feedback  control  of  a machining  process.  With  this  tool,  simple  corrective  actions 
may  be  implemented  such  as  linear  compensation  for  a controller,  or  a simple  mechanical 
adjustments,  or  simple  mechanical  repairs  or  even  overhauls,  or  even  simple  real-time  error 
compensation.  Ultimately,  the  development  of  these  types  of  error  analysis  software  tools  will 
enable  the  end  user  to  fully  utilize  the  data  obtained  from  standard  types  of  machine  tool  error 
measurements  (i.e.,  the  laser  and  the  ballbar).  These  are  the  main  two  projects  that  API  is 
working  on  that  directly  apply  to  the  NAMT  program. 

DONMEZ:  When  do  you  expect  to  complete  the  3-D  visualization  software? 

OLSON:  This  is  Phase  I of  an  SBIR  project.  Currently  we  are  writing  a proposal  for  Phase  II. 

We  need  to  perform  more  analysis  and  don’t  expect  a commercial  product  for  another  2 years. 
Since  it  is  not  a trivial  matter,  it  will  require  some  analysis  and  an  assessment  will  be  made  to 
determine  exactly  what  crucial  functions  to  include  in  such  a software  package. 

DONMEZ:  On  which  platforms  will  the  software  run? 

OLSON:  The  underlying  engine,  which  drives  the  software,  is  a solid  modeling  kernel  called 
Parasol.  That  is  what  builds  the  solid  models.  We  use  Visual  C and  Microsoft  C to  program  the 
User  Interface. 

KATTER:  What  does  the  Beta  software  consist  of? 

OLSON:  The  database  management  software  is  not  currently  delivered  with  the  5-D  laser  or 
ballbar.  We  reached  an  agreement  with  a user  who  bought  the  entire  series  of  measurement 
devices.  Since  the  customer  had  many  types  of  machine  tools,  API  thought  that  it  was  a good 
place  to  test  the  data  management  software.  It  has  been  out  there  for  about  3 or  4 months  now, 
we’re  looking  to  obtain  feedback  from  the  Beta  site  to  better  define  the  format  for  the  data  output. 
Feedback  in  terms  of  what  type  of  analysis  packages  would  be  beneficial.  We  would  be  willing 
to  work  with  other  people  as  well  and  provide  the  software  for  evaluation. 

COVINGTON:  We  are  interested  in  getting  a copy. 

OLSON:  I don’t  see  a problem  with  getting  a copy  of  the  software  to  Boeing. 

KATTER:  How  far  away  from  commercialization  is  the  6-D  laser  system  where  roll  is  also 
measured? 

OLSON:  API  is  developing  a 6-D  laser  system  where  roll  is  measured,  but  I am  not  certain  of  the 
specifics  of  when  that  will  be  available? 

COVINGTON:  Do  you  have  any  devices,  which  measure  4 axes? 

OLSON:  API  does  have  a device,  which  we  refer  to  as  a “swivel  check”.  We  have  an 
autocollimator,  but  doesn’t  work  well  on  the  rotary  axis. 
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KRULEWICH:  How  accurate  is  your  5-axis  system? 

OLSON:  For  our  standard  system,  linear  accuracy  is  lppm.  Our  high  accuracy  system  is  5 times 
more  accurate.  For  other  yaw  and  pitch  it  is  1 arc-sec.  For  straightness  I would  have  to  look  it 
up.  The  resolution  is  10  times  smaller. 
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Loaded  Machine  Data 
Steve  Patterson 

University  of  North  Carolina  at  Charlotte 


I want  to  talk  about  something  a little  different.  I’m  not  going  to  talk  about  the  database  or 
computer  models.  Each  time  we’ve  had  these  workshops,  I’ve  tried  to  talk  about  the  data  that 
will  be  used  in  the  data  repository.  What  I’m  trying  to  do  is  come  up  with  the  type  of  data  that  is 
not  easily  encapsulated.  I’m  just  going  to  give  one  example  of  that  by  talking  about  a class  of 
data  which  is  being  discussed  by  the  B5  committee,  which  is  loaded  machine  data. 

A lot  of  the  geometry  data  that  we’ve  been  discussing  so  far  today  have  been  using  metrology 
methods  to  measure  the  machine  tool  essentially  as  if  it  were  a CMM.  Questions  have  been 
raised  from  time  to  time  of  what  actually  happens  on  a machine  in  the  presence  of  loads  that  are 
there  when  the  machine  tool  is  actually  plunged  into  metal.  To  look  at  that,  we’ve  built  a setup 
using  one  iron  disk  and  a couple  of  relatively  strong  magnets.  By  varying  the  gap  between  the 
disk  and  the  magnets,  we  get  a pretty  smooth  load,  so  I don’t  have  to  worry  about  varying  rattle  in 
the  loading  device.  We  can  place  about  a hundred  pounds  or  so  of  force  on  the  spindle.  I will 
give  you  one  “characteristic”  result.  What  we  find  is,  of  course,  what  you  don’t  want  to  find 
when  you  go  out  and  do  this:  that  there  is  a definite  difference  between  unloaded  and  loaded 
performance  in  the  machine  tool.  What  is  even  more  interesting  is  that  when  you  do  this  at 
different  speeds,  there  is  no  simple  model  for  a particular  spindle.  This  particular  measurement 
was  made  on  a spindle  which  has  a Timken,  tapered  roller  bearing  on  the  nose,  hydraulically 
preloaded  from  a table  based  on  spindle  rpm.  The  pre-load  changes  as  a function  of  rpm  and 
results  also  change  as  a function  of  pre-loads,  so  it  is  a relatively  complicated  situation.  The  only 
real  contribution  that  I was  going  to  make  today  was  to  present  some  data.  There  is  still  some 
richness  in  the  area  of  machine  tool  testing  in  terms  of  having  a real  understanding  of  what  is 
going  on.  We  heard  earlier  about  questions  of  reconciling  the  difference  of  ballbar  data  with  laser 
measurement  data.  What  we  ultimately  want  to  do  is  reconcile  our  understanding  of  machine 
tools  with  the  parts  that  we’re  getting  off  of  them.  This  is  another  piece  of  the  puzzle,  which  is 
going  to  have  to  be  included  sooner  or  later. 

HEMMERLE:  Did  you  axially  pre-load  there?  Did  you  do  any  side  pre-loading? 

PATTERSON:  This  is  an  axial  pre-load.  I have  not  done  any  side  pre-loading  yet.  You  can  only 
do  so  much  with  a Masters  student  before  he  escapes. 

DONMEZ:  What  ranges  of  loads  did  you  use? 

PATTERSON:  We  varied  a gap  between  the  disk  and  the  magnets,  which  yielded  roughly  70- 
MO  lbs.  of  axial  load. 

DONMEZ:  It  seems  then  that  loading  essentially  creates  an  on/off  effect. 

PATTERSON:  Some  loading  experiments  yielded  a binary  response,  and  in  others  that  is  not  the 
case  between  loaded  and  unloaded.  At  1000  rpm,  you  don’t  see  any  difference  between  loaded 
and  unloaded. 

HEMMERLE:  Where  are  you  going  with  this?  What  is  your  next  Ph.D.  student  going  with  that? 
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PATTERSON:  These  numbers  are  not  huge,  for  some  applications  they  are  important.  There  is 
about  5 pm  of  difference  there.  For  some  of  us,  that  is  a big  number,  but  for  most  of  you  it’s  sort 
of  so-so.  One  of  the  other  things  that  I’m  interested  in  looking  at  is  the  error  motion  itself  when 
you  take  a look  at  the  asynchronous  and  the  synchronous  error  motion  and  how  that  is  changing 
with  load.  The  idea  being  basically  to  get  a handle  on  what  is  the  boundary  of  changes  between 
loaded  and  unloaded.  After  that,  seeing  if  we  can  reproduce  the  difference  in  parts,  which  is  the 
challenge. 

DONMEZ:  You  mentioned  1000  rpm  not  having  any  difference.  What  is  going  on  between 
1000  and  1500  rpm?  Is  it  again  an  on/off  switch? 

PATTERSON:  At  500  rpm,  it  behaves  like  you  would  expect  it  to,  with  increasing  pre-load 
causing  increasing  offset.  There  are  two  shifts  in  the  hydraulic  pre-load  that  occurs  in  the  spindle 
assembly  and  every  time  you  cross  a boundary  the  behavior  changes  not  only  quantitatively  but 
qualitatively  as  well. 

DONMEZ:  That  means  that  we  have  to  capture  information  about  the  loading;  the  loading  types 
and  the  amount  of  loading  in  some  of  the  data  that  we  have.  That  should  be  another  layer  of  our 
repository. 
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Techniques  for  Modeling  CNC  Machine  Errors 
Don  Esterling 
N-See  Software 


We  are  a company  that  has  been  in  the  verification  business  for  about  15  years.  Verification  can 
be  thought  of  as  error  modeling  for  a perfect  machine  — error  modeling  the  process  (the  part 
program)  rather  than  error  modeling  the  hardware.  At  the  last  meeting  in  New  Orleans  we 
discussed  the  utility  of  error  modeling  and  the  accuracy  that  is  required.  Often  large  and  small 
shops  each  have  a difficult  time  in  understanding  the  value  of  hardware  error  modeling.  There  is 
a parallel.  A few  years  ago,  Computer-Aided  Manufacturing  (CAM)  vendors  were  not  really 
interested  in  process  error  modeling  or  verification.  Now  you  can't  find  a CAM  package  that 
doesn't  have  some  type  of  verification  tool  imbedded.  The  mindset  changed  for  several  reasons. 
The  change  came  when  error  modeling/verification  was  recognized  as  reliable  and  cost  effective, 
enabling  part  program  mistakes  to  be  discovered  before  they  cause  costly  errors  on  the  shop  floor. 
It  is  also  much  more  convenient,  easier  and  you  can  do  a lot  more  in  simulation  than  you  can  do 
on  the  shop  floor. 

Today  I will  present  ways  of  modeling  error  sources  from  my  point  of  view.  [Slide  5-2].  When  I 
first  spoke  to  Alkan  Donmez  about  the  project,  I understood  the  project  as  starting  with  a 
collection  of  CNCs  on  the  shop  floor,  error  modeling  data  for  these  machines,  and  certain  part 
programs,  and  then  asking  the  question:  which  CNCs  are  the  best  choice  to  manufacture  products 
within  specified  tolerances.  That  is  what  I considered  as  our  challenge. 

The  verification  industry  has  spent  man-decades  of  time  developing  various  engines  to  model 
process  errors  for  a perfect  CNC.  The  hardware  errors  that  we  are  talking  about  with  CNC 
machine  tools  can  be  in  the  tens  of  micron  level  range  and  so  require  very  accurate  modeling 
tools.  What  are  the  lessons  to  be  drawn  from  modeling  comparably  sized  process  errors? 

There  are  various  ways  to  model  errors  on  a perfect  machine.  I will  describe  three  approaches. 

Some  verification  systems  use  animation  techniques,  but  these  are  accurate  along  the  viewing 
direction.  [Slide  5-3].  If  you  try  to  rotate  to  a new  view,  the  verification  system  will  have 
limitations  in  zooming  and  in  reporting  dimensional  data.  These  are  due  to  model  inaccuracies  in 
the  screen  X-Y  direction,  perpendicular  to  the  viewing  direction.  Typically,  the  accuracy  is  one 
pixel  in  size,  one  part  in  500  if  you  are  using  a 500  x 500-pixel  error  region.  This  translates  to 
2000  microns  over  a one-meter  part.  This  approach  is  also  relatively  slow.  The  main  issues  here 
are  speed  and  accuracy.  Error  modeling,  of  any  sort,  on  the  shop  floor  demands  high  accuracy 
within  a reasonable  time. 

There  have  been  various  CAD  modeling  schemes  for  verification,  which  are  very  helpful  in 
modeling  large  scale,  complex  work  cells.  [Slide  5-4].  For  the  metal  removal  process,  this 
approach  presents  you  with  a choice.  If  you  want  a reasonable  response  time,  then  there  is  a 
sacrifice  in  accuracy  as  can  be  seen  when  you  zoom  in  and  find  a smoothly  varying  surface 
approximated  by  flat  polygons.  Alternatively,  if  you  want  to  have  shop  floor  accuracy  for 
material  removal,  then  the  response  time  for  a complex  part  can  be  very  long. 

Another  alternative  and  the  path  that  we  chose  to  take,  is  to  develop  our  own  internal  modeling 
engines  tuned  to  CAM,  rather  than  CAD,  applications.  [Slide  5-5].  We  started  out  with  a CAD 
solid  model  system  and  realized  that  there  is  a brick  wall  there  in  terms  of  the  type  of  technology 
needed  to  develop  CAM-specific  solid  models;  one  which  will  handle  very  large  part  programs. 
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To  give  you  a sense  of  what  we've  had  to  deal  with,  recently  we  were  benchmarked  by  a vendor 
who  was  evaluating  us  against  other  products.  They  gave  us  Vi  million  lines  of  code  with  a very 
mild  gouge  somewhere  and  told  us  to  find  it.  It  took  us  2.5  minutes  on  a Pentium  Pro  200  to  find 
the  gouge.  That  is  the  type  of  response  time  we  need  to  deliver.  That  is  a lot  faster  than  the  CNC 
can  process  the  part,  which  would  be  about  several  hours,  and  we  are  still  able  to  maintain  shop 
floor  accuracy.  A CAD-based  solid  modeler  would  take  a lifetime,  if  ever,  to  process  that 
number  of  Boolean  operations  (one  per  tool  cut)  at  that  level  of  accuracy. 

I will  now  demonstrate  our  part  verification  product.  [Slide  5-6].  This  presentation  will  consist  of 
2-axis  turning,  3-,  4-,  and  5-axis  milling.  We  provide  pixel-based  animation,  which  is  very  useful 
for  seeing  large  errors  or  unexpected  tool  motion.  We  also  have  solid  modeling  for  turning  and 
milling  where  you  can  rotate  to  any  view,  zoom  in  for  details  and  obtain  accurate  dimensional 
data  anywhere  on  the  part.  [Slide  5-7  to  5-10].  The  system  allows  you  to  even  see  scalloping 
effects,  basically  errors  at  any  level  of  interest,  particularly  errors  required  for  the  NAMT 
objectives.  [Slide  5-11]. 

When  you  have  humans  in  the  loop,  things  happen  that  sometimes  you  don't  expect.  The  nice 
thing  about  our  model  is  that  it  models  the  machine  exactly  as  it  behaves.  If  it  goes  wrong  on  the 
shop  floor,  you  can  see  it  in  our  software.  Here  is  the  surface  of  the  benchmark  part,  and  if  you 
look  carefully,  you  can  see  a small  gouge.  [Slide  5-12].  Here  is  the  surface  of  the  part  as  it 
compares  with  the  CAD  data.  We  can  import  a CAD  model  and  superimpose  the  CAD  model 
over  the  part.  [Slide  5-13].  The  different  colors  indicate  where  you  have  over  cut  and  under  cut 
the  part.  If  I zoom  in  to  the  critical  region  where  the  gouge  is,  you  can  see  how  deep  the  gouge  is. 
[Slide  5-14]. 

This  is  not  a pixel  model;  it  is  a solid  model.  One  of  the  characteristics  of  a true  solid  model  is 
that  you  can  zoom  in  to  any  point  of  view.  That  was  just  a short  demonstration  of  our  current 
capabilities. 

What  we  did  about  a year  ago  in  response  to  that  NAMT  request,  was  model  a simple  turned  part, 
along  with  an  error  model  that  had  been  developed  by  Alkan's  group.  [Slide  5-18].  We 
demonstrated  the  feasibility,  within  a reasonable  response  time,  to  accurately  model  very  small 
errors  for  a lathe.  We  simulated  a simple  step  part  for  a particular  CNC.  The  model  provided  in 
an  automated  way  a means  to  visualize  the  errors  on  the  part  caused  by  the  machine  errors, 
similar  to  what  API  showed. 

We  are  interested  in  developing  a milling  CNC  error  model,  where  the  challenges  are  somewhat 
different  than  turning.  [Slide  5-19].  Turning  is  a 2-D  model  with  a 2-D  error  model 
superimposed  on  top  of  that.  You  don't  really  need  solid  modeling  to  do  that  sort  of  thing.  When 
you  get  into  milling,  particularly  if  you  want  to  model  the  entire  process,  not  just  the  finishing 
process,  and  you  have  a part  with  significant  lines  of  code,  you  want  to  have  a model  that  will 
handle  at  least  a perfect  CNC  system.  How  can  you  handle  CNC  hardware  errors  if  you  can't 
even  model  a perfect  CNC?  We  have  something  that  will  exactly  model  the  machine  tool  to  the 
errors  that  you  are  introducing.  We  are  interested,  but  first  need  to  hear  from  some  of  you  as 
well. 
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A Summary  of  Machine  Tool  Error  Visualization 
Using  Deneb  Robotics  Simulation  Software 
Joe  Falco 

National  Institute  of  Standards  & Technology 


The  Intelligent  Systems  Division  has  developed  an  error  visualization  tool  for  displaying  machine 
tool  errors  in  the  form  of  error  vectors  based  on  a set  of  polynomial  equations  for  a given  machine 
tool.  The  visualization  tool  also  displays  the  machine  tool  and  a “ghost”  image  of  the  machine 
tool  to  depict  machine  offsets  do  to  the  errors.  The  visualization  tool  was  developed  using  Deneb 
Robotics  Envision  Software  (formerly  IGRIP  and  TGRIP).  The  Envision  software  plots,  within 
its  3 dimensional  environment,  both  a desired  machine  tool  trajectory  based  on  an  NC  program 
and  the  actual  machine  tool  trajectory  as  predicted  by  a set  of  polynomial  equations  that  model 
the  machine’s  errors.  The  software  user  has  the  option  of  specifying  an  interpolation  variable  for 
finer  position  resolution,  and  can  magnify  the  resulting  error  vector  representations  using  a 
scaling  factor.  Vector  entities  are  then  drawn  within  the  3-dimensional  environment  between 
each  trajectory  point  and  the  associated  error-induced  point.  The  scaled  vectors  are  overlaid  on  a 
solid  model  of  the  ideally  machined  part  and  are  color  coded,  red  indicating  the  that  the  machines 
errors  resulted  in  the  removal  of  excess  material  and  green  the  opposite.  In  addition  to  the  scaled 
vector  representation  of  the  machine  errors,  the  visualization  tool  also  displays  the  machine  tool 
during  the  generation  of  vectors.  Two  machines  are  displayed  simultaneously,  one  being  that  of 
the  actual  machine  tool  which  tracks  the  error  induced  NC  trajectory,  and  the  second,  a 
transparent  “ghost”  machine  tool  which  tracks  the  nominal  NC  program  trajectory.  The 
geometry  of  the  modeled  part  is  not  changed  based  on  the  machine  tool  errors  nor  are  the 
individual  machine  error  components  modeled  onto  the  simulated  machine  tool.  We  used  Deneb 
software  to  help  us  model  errors  in  our  machining  process.  Essentially,  what  we  did  was  take 
Alkan  Donmez’s  error  model,  which  was  a polynomial,  and  fed  the  error  models  into  the  Deneb 
software.  This  is  just  a visualization  tool,  which  allowed  us  to  model  the  Monarch  Turning 
Center.  [Slide  6-1  to  6-4].  We  show  the  actual  machine  tool  with  the  errors  introduced,  where 
there  is  a ghost  image  of  where  the  nominal  part  should  be.  [Slide  6-5  to  6-8].  You  can  see  the 
ghost  image  of  the  desired  paths  and  show  the  actual  path  as  it  occurs,  green  indicates  positive 
error  and  red  indicates  negative  error.  [Slide  6-9  to  6-1 1]. 

DEFORGE:  Would  you  tell  people  what  you  are  running  on  as  far  as  the  hardware  platform. 

FALCO:  This  is  a Pentium  120  MHz  laptop.  We  typically  use  Silicon  Graphics  and  other  higher 
end  machines  for  normal  use. 

CHANDRA SEKHARAN:  How  are  you  rendering  the  ghost  image  and  the  true  path  image? 

FALCO:  That  is  all  written  in  the  Deneb  software.  Essentially  we  have  two  machines,  (1)  the 
nominal,  and  (2)  the  machine  with  the  error  model,  and  we  display  them  both  at  the  same  time. 
We  had  to  perform  some  preprocessing  since  we  are  using  the  laptop  for  demonstration.  On  an 
SGI,  the  computations  are  fast.  You  can  vary  your  resolution  for  computations,  which  will  also 
vary  the  speed  in  which  you  obtain  your  result.  We  have  also  created  a similar  application  using 
“Envision”  for  our  Octahedral  Hexapod  where  we  are  able  to  visualize  the  error  characteristics  of 
a five-axis  machine. 

DEFORGE:  One  of  the  things  that  you  might  want  to  explore,  if  you  do  any  further  work,  is  at 
each  one  of  those  locations  you  could  actually  lay  out  tag  points  that  you  are  familiar  with.  Then 
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you  could  fill  the  tag  point  with  whatever  quantified  values  you  wanted.  Then  you  could  query 
the  tag  points. 

FALCO:  I am  currently  using  tag  points. 

KRULEWICH:  Can  you  model  spindle  errors?  Can  you  see  the  surface  finish  caused  by  tool 
marks,  does  it  take  into  consideration  the  shape  of  the  tool? 

FALCO:  That  would  be  a very  detailed  calculation. 

DEFORGE:  You  might  be  able  to  do  that  if  you  turn  on  the  material  removal  option.  It  depends 
on  how  large  the  errors  are.  The  last  meeting  we  brought  out  that  some  of  these  algorithms  and 
functions  of  errors  can  be  simulated,  but  may  be  computationally  intensive.  We  are  at  a point  in 
the  technology  where  we  in  the  software  business  come  up  against  the  hardware  limitations.  If 
you  want  to  do  this  simulation  at  the  same  time  you  do  material  removal,  at  the  same  time  that 
you  are  doing  motion  planning  and  things  of  that  nature,  what  that  means  is  you  may  be  looking 
at  two  days  of  computation.  However,  if  we  can  take  parts  of  the  problem  and  look  at  each  one 
separately,  the  computation  is  manageable.  Turning  is  simple. 

ESTERLING:  What  you’re  saying,  that  with  your  technology  the  material  removal  process  is 
relatively  slow.  Material  removal  is  where  our  strength  is.  We  are  able  to  model  machine  tool 
errors  fairly  rapidly. 

DONMEZ:  An  issue  that  was  brought  up  at  the  last  meeting  was  whether  or  not  we  were  going 
to  be  concentrating  on  part  only  or  machine  only  information  or  some  combination  of  both. 
Machine  only  information  could  be  provided  to  the  maintenance  people.  If  you  have  error 
information,  you  can  show  the  machine  behavior. 

DEFORGE:  From  a technology  point  of  view,  what  I am  interested  in  hearing  from  this 
organization  is  what  you  think  the  end  users  are  going  to  want  as  far  as  a visualization  tool.  The 
data  collection  is  wonderful.  However,  how  do  you  expect  our  software  to  tap  into  the  data 
collected?  How  do  you  ultimately  want  to  see  the  data  represented?  I think  visualization  is  key, 
because  there  is  so  much  information  available  that  the  guys  on  the  shop  floor  are  not  going  to 
look  at  numbers.  However,  if  we  can  incorporate  those  numbers  into  a picture  to  show  them 
where  areas  of  concern  are  on  the  machine  tool,  that  would  be  great.  How  are  we  going  to  take 
that  approach?  I think  it  would  be  nice  to  map  out  regions  of  a work  envelope  on  a machine, 
which  would  be  of  concern.  You  can  then  fixture  your  workpiece  within  the  work  volume  to 
maintain  a tolerance  on  a part.  That  would  be  a useful  tool  for  those  on  the  shop  floor.  My  other 
concern  is  implementation,  how  often  do  those  zones  change?  These  are  answers  that  I need  in 
order  to  give  our  developers  a direction  to  proceed. 
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Activities  at  Lawrence  Livermore  National  Laboratory: 

Debbie  Krulewich 

Lawrence  Livermore  National  Laboratory 

I brought  a couple  of  viewgraphs,  (1)  that  talks  about  LLNL  and  where  they  are  in  terms  of  this 
workshop,  and  (2)  talks  about  specific  areas  of  concern  that  we’re  facing.  I also  brought  outputs 
of  our  data  acquisition.  We  are  lucky  to  have  Sam  Thompson  at  this  meeting  who  is  the 
developer  of  most  of  the  data  acquisition  of  all  of  our  metrology. 

We  actually  don’t  do  a good  job  of  archiving  the  performance  history  of  our  machine  tools. 

[Slide  7-2].  When  a machine  has  a problem,  we  may  partially  characterize  a machine.  If  we  have 
a problem  five  years  later  with  the  same  machine,  we  are  lucky  to  find  an  old  folder  that  someone 
has;  we  may  find  old  strip  chart  recordings.  We  really  don’t  have  a good  way  of  archiving 
information.  I think  it  would  be  very  useful  if  we,  at  Livermore,  had  a good  way  of  recalling  the 
history  of  characterization  for  a particular  machine  tool.  The  second  goal  is  related  to  a project 
on  which  I am  currently  working.  When  you  are  error  budgeting  for  a new  machine,  you  need 
some  type  of  general  knowledge  about  certain  errors.  I don’t  have  the  historical  experience.  For 
example,  Donaldson  has  the  experience  to  tell  you  what  types  of  errors  to  expect  if  you  put  an  air- 
bearing spindle  on  your  machine.  There  are  so  many  people  who  measure  machine  tool  errors 
that  it  seems  like  it  would  be  very  useful  to  have  a database  with  error  budgeting  information. 

For  example,  if  you  had  a machine  with  this  type  of  spindle  and  this  type  of  pre-load,  etc.,  then 
here  is  a range  of  accuracy  that  this  spindle  will  provide. 

We  are  doing  some  work  in  cutting  simulations.  I would  like  to  avoid  performing  experiments  to 
obtain  the  cutting  coefficients,  which  are  dependent  on  the  type  of  material,  type  of  tool,  the  rake 
angle,  etc..  Since  so  many  people  perform  experiments  to  obtain  those  coefficients,  the  repository 
should  contain  the  results  such  that  experiments  don’t  have  to  be  replicated. 

These  are  my  concerns  as  we  discuss  the  format  of  saving  data  vs.  the  sampled  rate.  [Slide  7-3]. 

It  is  a little  confusing  to  try  to  figure  out  whether  you  are  talking  about  spatial,  temporal.  When 
you  are  taking  data  point  to  point,  it  is  hard  to  figure  out  what  the  spatial  sampling  frequency  of 
the  data  that  you  are  storing.  The  way  that  the  data  is  represented  is  very  dependent  upon  these 
things.  I was  able  to  sit  in  on  a meeting  pertaining  to  spindles.  Analog  filtering  was  a hot  topic  at 
that  meeting.  People  have  very  strong  opinions  on  both  sides  of  whether  or  not  you  should  filter 
your  spindle  data.  The  data  is  very  different  depending  on  whether  or  not  you  filter.  How  you 
know  what  types  of  preprocessing  has  been  done  to  the  data  prior  to  storage  in  the  repository. 

I have  brought  up  sign  convention  before.  If  you  are  trying  to  compensate  or  simulate  errors, 
there  is  a lot  of  confusion  on  sign  convention;  especially  if  your  part  is  on  a moving  axis. 

What  is  the  distribution  of  your  apparent  non-repeatable  error  terms  of  your  machine. 

I wanted  to  show  you  outputs  from  our  data  acquisition  system  that  Sam  Thompson  wrote. 
Basically,  this  is  a spreadsheet  and  acts  as  our  history  chart  recorder.  The  software  is  fairly  user 
friendly,  it  gives  the  user  what  the  ranges  are,  it  prompts  the  user  for  comments.  This  is  one 
output  of  spindle  growth  tests. 

This  is  a straightness  measurement.  [Slide  7-4  to  7-8].  The  way  Sam  has  the  program  written  is 
that  it  asks  the  user  for  important  information,  for  example,  the  software  locates  the  measurement 
line  based  on  the  user  input. 
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We  are  taking  error  measurements,  typically  taken  in  free  space,  where  we  try  to  find  the  actual 
errors  on  the  part.  Rather  than  taking  measurements  while  the  machine  is  loaded,  we  are  taking 
the  measurements  that  correspond  to  the  motion  of  the  tool  in  free  space.  We  are  trying  to 
consider  the  machine  process  as  a nonlinear-type  of  transfer  function  in  the  frequency  domain.  I 
am  trying  to  develop  an  error  budgeting  tool  that  predicts  the  final  errors  on  a part  in  a continuous 
spatial  frequency  sense.  [Slide  7-9  to  7-12].  A conventional  error  budget  may,  for  example, 
address  waviness  and  surface  finish.  This  continuous  error  budget  will  give  you  continuous 
amplitude  vs.  spatial  frequency  of  a part.  I’m  running  into  measurement  issues.  What  I need  are 
errors  that  are  characterized  in  the  frequency  domain.  It  is  forcing  me  to  take  measurements  on 
the  fly.  The  data  that  I have  been  collecting  is  finely  spaced.  I am  also  interested  in  obtaining  a 
probability  distribution  for  the  non-repeatable  errors.  Every  time  you  measure  errors,  they  may 
not  be  exactly  the  same. 

I have  been  trying  to  work  out  a positioning  error  in  spatial  frequency  domain.  This  data  was 
taken  on  a lathe.  The  graph  on  the  upper  left  is  where  I took  data  every  10  micro  inches.  I took 
data  by  hand  over  two  revolutions  of  the  ball  screw.  Two  revs  are  the  large  pattern.  There  is  a 
high  frequency  error  that  occurs  1600  times  every  inch.  It  was  exactly  every  320  times  per 
revolution  of  the  ball  screw.  It  was  very  regular.  This  machine  was  being  brought  into 
production  and  I had  a chance  to  look  at  the  way  that  others  took  data  on  this  machine.  They 
were  doing  positioning  tests  with  the  values  of  the  position  in  lookup  tables.  They  took  data 
every  5 mm  (1/5  inch),  which  caused  aliasing  in  the  high  frequency  error.  When  they  input  their 
“corrected  points”  in  the  tables,  the  machine  was  worse  than  when  they  started. 

HEMMERLE:  Ray,  can’t  you  answer  the  question  of  what  that  cyclic  feedback  is? 

KRULEWICH:  I would  like  to  know  if  that  is  a regular  phenomena  or  is  what  I measured  a 
fluke. 

HEMMERLE:  My  major  error  loss  in  whole  producing  capability  is  cyclic  error  in  inductosyns. 
KRULEWICH:  What  is  the  frequency? 

HEMMERLE:  It  can  be  pretty  high,  depending  how  you  look  at  it.  Linearly,  if  you  have  a metric 
feedback  system  and  you  are  looking  at  an  inch,  look  at  every  3 inches  and  you’ll  get  10%  of  the 
maximum.  That  is  how  I determine  the  cyclic  error  on  an  inch  measurement.  On  the  rotary,  I use 
an  inclined  surface  plane,  which  is  automatic. 

KRULEWICH:  I have  an  encoder.  I didn’t  have  the  opportunity  to  take  any  time-based 
measurements.  That  is  the  next  experiment  that  I will  be  performing.  What  I want  to  do  is 
trigger  off  of  position. 

DONMEZ:  Is  this  a regular  type  of  ball  screw  with  a regular  plane- wave  error? 

KRULEWICH:  Yes. 

HEMMERLE:  You  always  get  a certain  amount  of  ticking,  no  matter  what  your  increment? 
High/Low,  High/Low? 

KRULEWICH:  No.  I did  the  test  at  many  different  sampling  rates  and  I didn’t  just  see  a 
High/Low  pattern.  In  addition,  when  I showed  this  to  other  colleagues  who  are  interested  in 
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vibration  data,  they  concluded  that  it  was  not  time-based.  It  is  spatial  frequency.  Because  I was 
not  taking  data  at  regular  time  intervals,  but  spatial  intervals. 

SOONS:  I had  the  exact  thing  happen  to  me  when  I was  working  with  a ball  screw  experiment.  I 
didn’t  take  the  standard  approach  of  using  randomized  sampling  intervals.  I did  use  regular 
sampling  and  started  zooming  in,  where  my  sampling  got  smaller  and  smaller.  I ended  up  tracing 
the  periodic  error  of  the  scale.  Yours  may  be  a similar  problem. 

KRULEWICH:  The  first  two  bullets  that  I raised,  where  I talk  about  the  conventional  error 
budget,  and  where  the  physical  error  source  is  identified,  I’m  thinking  that  the  next  step  will  be  to 
take  a Fourier  Transform  or  FFT  of  the  data.  The  next  step  will  be  to  transform  the  errors  into  the 
frequency  domain  then  sum  them  in  the  frequency  domain,  but  I’d  like  to  talk  to  you  about  that 
more.  All  of  this  is  for  an  error  budget  that  doesn’t  exist.  The  biggest  thing  for  this  work  is  that  I 
need  to  get  a better  feel  for  classifying  error  components  on  machine  tools  to  their  corresponding 
frequency.  I have  one  machine,  which  I will  be  fully  characterizing,  in  the  frequency  domain. 
This  project  resulted  from  another  project  where  we  are  manufacturing  optics,  the  tolerance 
specifications  on  the  optics  is  in  the  continuous  frequency  domain,  or  actually  power  spectral 
density,  and  somehow  that  relates  to  the  transfer  function  of  the  optics.  Therefore,  the  problem  is 
continuous  from  form  error  to  the  high  frequency  errors.  That  project  along  with  other  projects  is 
driving  the  need,  at  least  at  Livermore,  perhaps  in  other  industries  as  well.  One  other  thing  that  is 
interesting  is  the  material  removal  transfer  function  is  different  from  the  conventional  approach. 
We  are  just  starting  to  formulate  a transfer  function  to  relate  the  motion  of  the  machine  tool, 
which  contains  a superposition  of  sine  waves  in  space,  and  it’s  resulting  effect  on  the  part.  We 
are  trying  to  work  with  Northwestern  University  on  this  problem.  There  are  certain  frequencies 
that  the  machine  will  filter  out,  which  will  not  appear  on  the  part.  On  the  other  hand,  if  you 
excite  resonances  on  the  machine,  then  you  will  see  amplified  effects  on  the  part. 

SOONS:  How  do  you  incorporate  thermal  errors  with  the  power  spectral  density  error  budget. 

KRULEWICH:  There  are  two  parts  to  that  question.  The  first  is  the  combinatorial  rule.  At  the 
same  time  you  obtain  a conventional  error  budget,  you  account  for  correlated  and  non-correlated 
components.  It  ends  up  not  being  a Root  Mean  Square  (RMS)  type  of  position  when  you  talk 
about  adding  up  sine  waves.  I make  a general  assumption  that  all  thermal  errors  are  correlated, 
and  all  other  errors  are  not  correlated.  The  second  thing  is  that  I treat  thermal  errors  as  basically  a 
very  low  frequency  to  DC  component.  So  the  plot  that  I showed  had  some  thermal  errors  seen  by 
the  slope  of  the  curve.  I plan  to  remove  the  slope  and  then  account  for  the  slope  using  thermal 
errors  in  an  additive  manner. 
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Calculation  of  CMM  Measurement  Uncertainty  via  the  Method  of 
Simulation  by  Constraints 
Dan  Sawyer 

National  Institute  of  Standards  & Technology 

Steve  Phillips  requested  that  I give  this  talk  in  his  absence.  This  is  an  exciting  new  concept  in 
Coordinate  Measuring  Machine  (CMM)  measurement  uncertainty  that  we’ve  been  working  on  at 
NIST.  I will  talk  about  the  calculation  of  CMM  uncertainty  and  more  specifically,  I will  talk 
about  the  new  method  of  CMM  uncertainty  calculation  by  use  of  constraints.  Dr.  Steve  Phillips  is 
the  project  leader.  I’ve  been  working  on  the  project  for  about  3 years,  and  I will  do  my  best  to 
describe  what  we  have  been  doing. 

First,  I’ll  quickly  overview  measurement  of  CMM  uncertainty,  which  may  be  an  introduction  to 
some  of  you.  [Slide  8-2].  The  characterization  of  geometry  errors  in  CMMs  has  a lot  of 
similarity  on  how  you  characterize  geometrical  errors  in  3-axis  machine  tools.  I’ll  talk  about 
computational  approaches  to  determine  CMM  measurement  uncertainty,  then  I’ll  show  the 
method  by  constraints. 

The  CMM  measures  parts  [Slide  8-3].  More  specifically  the  CMM  determines  part  features.  It 
may  be  determining  the  diameter  of  the  cylinder,  or  may  be  inspecting  the  perpendicularity  of  the 
axis.  The  fundamental  output  of  the  CMM  is  not  a feature,  but  a discrete  point.  We  use  a 
processor  to  take  a collection  of  discrete  points  and  generate  substitute  geometry  (i.e.,  a cylinder). 
Associated  with  each  one  of  those  points,  is  a measurement  error.  Ways  are  not  manufactured 
perfectly  flat  and  we  do  have  associated  errors  (i.e.,  angular)  that  aren’t  perfectly  modeled  and 
compensated.  The  measurement  error  is  then  propagated  to  the  feature-fitting  algorithm.  Error  in 
this  respect  is  defined  as  the  measured  minus  the  true  value.  If  we  knew  the  true  value,  we 
wouldn’t  need  to  take  any  measurements.  We  have  a concept  of  uncertainty  to  help  express  the 
“true”  value. 

This  slide  helps  describe  the  error  in  the  CMM  measurement  and  its  uncertainty.  [Slide  8-4].  We 
have  a sketch  of  a 3-D  CMM  work  volume,  where  the  ellipsoidal  regions  represent  the  CMM 
uncertainty.  They  change  in  size  and  orientation  as  you  vary  the  work  volume. 

What  factors  effect  the  uncertainty  in  my  measurement  of  features  (i.e.,  a simple  circle)? 

[Slide  8-5].  There  are  several  such  as  algorithm  selection  and  fitting  and  extrinsic  factors  such  as 
contamination  and  fixturing.  I will  talk  about  those  as  well  as  part  form  errors.  I will  also  talk 
about  geometric  modeling  errors  and  probing  errors,  which  we  have  a new  model  developed  at 
NIST  to  characterize  the  systematic  behavior  of  a touch  trigger  probe,  not  the  analog  probe  but 
the  TP2  type  with  a 3-prong,  kinematics  seat.  We  have  preferential  triggering  directions.  We 
have  a model,  which  backs  out  errors  associated  with  the  orientation  of  the  probe  axes.  I will  also 
talk  about  sampling  strategy  and  its  relation  to  CMM  measurement  uncertainty.  The  goal  of  this 
project  is  to  determine  feature  measurement  uncertainty  through  simulation.  We  use  a sampling 
strategy  to  propagate  the  CMM  errors  into  the  feature  measurement.  Sometimes  people  don’t 
understand  the  relationship  between  sampling  strategy  and  measurement  uncertainty. 

This  viewgraph  shows  a circular  feature  inspected  with  three  points.  [Slide  8-6].  Associated 
with  each  of  these  points  is  a random  radial  uncertainty.  In  this  case,  the  uncertainty  is  1 pm. 

The  problem  with  the  vertical  axis  is  the  standard  deviation  of  multiple  measurements  of  that 
circular  feature  using  the  same  sampling  strategy.  That  is,  at  120°  (which  refer  to  the  angle 
between  2 and  3 measurement  points)  we  see  that  the  standard  deviation  of  the  measured  points  (I 
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think  we  measured  1 00  points)  is  close  to  zero.  That  is,  we  measured  symmetric  sampling  points 
around  this  feature,  which  resulted  in  a very  small  uncertainty  of  measurement  of  that  radius.  The 
point  that  I am  trying  to  make  is  the  intended  angle  of  these  three  points  is  sufficiently  close.  The 
uncertainty  is  two  orders  of  magnitude  greater,  100  pm.  The  sampling  strategy  is  a very 
important  consideration  in  terms  of  our  feature  measurement  uncertainty.  We  have  a good 
analytical  model  that  describes  this  behavior  at  least  for  three  points.  Once  you  increase  the 
number  of  points,  then  the  model  breaks  down,  since  the  problem  is  more  complex.  I will  show 
you  some  data  that  we’ve  taken  with  multiple  probes.  People  understand  this  problem  but  in  the 
real  world,  simple  circles  are  not  the  most  complex  features  of  interest. 

There  are  often  issues  with  relational  measurements.  [Slide  8-7].  In  this  figure,  the  feature  of 
interest  is  the  total  radius,  which  is  the  perpendicular  distance  between  the  center  of  the  circle 
defined  by  this  partial  arc  and  the  axis  of  the  bore.  We  can’t  sample  the  full  range  of  the  bore. 

The  challenge  is  how  to  assign  uncertainty  to  the  radius.  There  is  uncertainty  in  measured  points, 
uncertainty  in  the  substitute  geometry  due  to  the  fitting,  uncertainty  associated  with  the  axis  and 
with  the  location  of  the  center  of  the  tool.  There  are  two  primary  approaches  to  assigning 
uncertainty,  or  assessing  the  machine  performance  in  these  types  of  measurements.  The  first  is  to 
create  a master  part,  which  means  every  time  I modify  a part,  I have  to  generate  a master  part.  I 
have  to  gauge  with  another  method  that  completely  characterizes  that  part.  I then  measure  that 
part  on  the  CMM  and  know  its  geometry  perfectly.  In  the  real  world,  we  measure  the  parts  as 
they  come  off  of  the  assembly  line  and  to  have  to  check  the  assembled  part  against  a master  part, 
that  is  extremely  expensive  and  impractical.  It  is  done  in  practice  and  perfectly  viable,  but  not  the 
best  solution. 

Another  approach  that  is  being  used,  is  to  simulate  the  measurement  process.  [Slide  8-8].  The 
goal  of  simulation  is  to  capture  task-specific  measurement  uncertainty  from  non-task-specific 
data.  What  is  meant  by  task  specific  measurement  is  that  we  want  to  calculate  the  measurement 
uncertainty  given  the  sampling  strategy.  I’m  not  trying  to  optimize  anything.  If  the  CMM 
operator  wants  to  inspect  four  specific  points,  what  is  the  most  accurate  result  to  expect  from  a 
specific  machine?  We  don’t  want  to  measure  a part  with  a sampling  strategy  that  is  associated 
with  a high  measurement  uncertainty.  There  are  apparently  two  approaches  to  this  technique.  The 
first  is  used  by  PTB  (Physikalisch  Technische  Bundesanstalt) , and  that  is  to  fully  characterize  the 
primary  source  of  errors,  geometric  errors,  for  a 21 -degree  of  freedom  model.  [Slide  8-9].  PTB 
measures  each  of  the  2 1 error  parameters,  then  fit  functions  to  the  data  and  they  use  the 
kinematics  equations  that  they  derive  from  their  sampled  data  to  propagate  errors  into  their 
measurement.  The  rigid  body  model  then  serves  to  characterize  the  machine.  They  use  the 
kinematics  equations  and  the  sampling  strategy  to  determine  the  part  measurement  error.  The 
problem  with  this  method  is  that  there  is  an  uncertainty  with  the  determination  with  those  errors. 
We  can’t  measure  those  errors  perfectly.  PTB  realizes  that  the  errors  aren’t  measured  perfectly, 
so  they  slightly  perturb  the  functions  with  some  specified  method.  They  have  a criteria  by  which 
they  perturb  the  functions.  Then  they  measure  a different  kinematics  state  and  generate  a new  set 
of  errors.  They  perform  this  process  several  times  to  obtain  errors  for  different  kinematics  states. 
The  standard  deviation  of  the  part  errors  gives  a measure  of  the  feature  measurement  uncertainty. 
The  perturbation  analysis  results  a space  of  possible  measurement  errors,  where  they  obtain  a 
statistically  significant  number  of  samples  to  obtain  the  measurement  standard  deviation.  This 
process  is  perfectly  valid.  We  performed  this  process  at  NIST  when  a gentleman  from  PTB 
visited  and  worked  with  Bruce  Borchard,  a colleague  from  NIST.  They  performed  measurements 
on  an  artifact  for  three  days  where  they  wrote  a part  program,  measured  12  different  positions  of 
the  CMM  and  several  different  probe  offsets,  and  were  able  to  back  out  a particular  set  of  error 
metrics  that  described  the  geometric  errors  of  the  machine.  This  is  a perfectly  valid  approach. 
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The  second  approach  is  what  I am  here  to  present  to  you,  the  simulation  by  constraint  algorithm. 
[Slide  8-10].  What  we  are  using  is  incomplete  information.  We  look  at  performance  evaluation 
data  from  a standard  (i.e.,  ASME  B89)  and  try  to  determine  a possible  population  of  kinematics 
states.  The  kinematics  states  that  we  generate  may  have  completely  different  values  for 
parametric  errors.  All  of  them,  when  used  in  simulation,  reproduce  the  performance  evaluation 
data,  where  the  performance  numbers  in  the  simulation  bound  them  and  we  discard  any 
kinematics  states  that  the  machine  cannot  occupy.  We  obtain  the  performance  numbers  from 
ASME  B89,  “The  Method  of  Performance  Evaluation  of  Coordinate  Measuring  Machines”. 

[Slide  8-11].  To  implement  this  method  on  machine  tools,  you  might  use  the  ASME  B5.54.  The 
particular  numbers  that  we  use  are  repeatability,  linear  displacement  accuracy  and  the  volumetric 
performance.  These  six  numbers,  collectively,  are  sensitive  to  every  possible  geometric  error. 
That  is,  if  you  think  about  the  parametric  model  for  a simple  CMM,  then  assign  the  Z-axis  to  be 
the  ram  axis.  If  you  measure  every  part  with  the  vertical  ram  then  you  are  insensitive  to  Z-axis 
roll;  you  never  see  any  effects  from  Z-axis  roll  in  any  of  your  measurements.  If  you  were  to 
calculate  these  parametric  states,  you  would  be  unable  to  confine  the  Z-axis  roll  terms.  I will 
explain  the  model  in  further  detail  to  illustrate  my  point.  We  use  the  B89  performance  data  to 
calculate  the  population  of  possible  machine  states.  These  machine  states  have  a widely  varying 
possibility  of  parametric  functions.  However,  when  we  use  each  one  of  these  machine  states  in 
simulation  to  produce  tests,  we  get  the  performance  data  for  all  possible  machine  states.  If  I don’t 
have  the  information  to  fully  characterize  the  machine,  then  this  is  a valid  approach  to  discard  the 
states  that  are  not  possible.  We  then  take  each  possible  state,  and  we  measure  our  part  given  a 
sampling  strategy,  which  gives  us  a population  of  measurement  uncertainty  (standard  deviation). 

The  interface  for  this  approach  looks  like  the  following.  [Slide  8-12].  Dr.  Phillips  developed  the 
model  for  this  method  while  in  parallel  we  have  had  ICAMP  Company  work  on  the  interface  with 
the  model.  This  interface  doesn’t  have  the  full  functionality  of  the  model,  but  this  will  give  you 
an  idea  of  what  it  looks  like.  Part  geometry,  you  can  select  a feature  of  interest  (i.e.,  a circle  or 
cylinder).  The  number  of  simulations  is  the  number  of  virtual  states  that  you  want  to  calculate. 
You  can  then  determine  where  significant  changes  are  occurring  in  the  measurement  error.  With 
the  inspection  process,  you  specify  your  sampling  strategy,  (i.e.,  position  and  orientation  of 
probed  points  on  the  part).  The  inspection  machine,  you  specify  performance  specifications, 
which  are  sensitive  to  all  the  geometrical  errors.  When  you  run  the  simulation  for  a best-fit 
circle,  you  end  up  with  a standard  deviation,  a,  of  the  measured  radius.  The  uncertainty,  U,  is  2a. 
The  interface  is  still  under  development,  in  particular,  we  are  still  developing  the  inspection  plan. 
The  process  of  inputting  points  is  very  difficult,  where  you  have  to  specify  the  points  (parameter 
space)  by  the  percentage  of  your  feature  of  interest.  For  example,  if  you  want  to  measure  1 80°  of 
an  arc,  and  then  specify  the  measurement  of  one  line  at  0 to  50%.  These  are  the  types  of  issues 
we  are  working  on  with  the  interface  to  the  model. 

After  the  model  simulation  was  running,  we  decided  to  test  the  robustness  of  the  model  with  a 
simple  measurement.  [Slide  8-13].  We  decided  to  investigate  point  to  point  measurements  of  a 
step  gauge  in  the  work  volume.  We  measured  a step  gauge  at  several  different  positions  in  the 
work  volume  (i.e.,  horizontal,  high  horizontal,  low  horizontal,  face  diagonals,  etc.)  and  looked  at 
the  CMM  measurement  error  and  made  an  uncertainty  prediction  based  on  the  numbers  that  I 
showed  earlier.  This  is  the  result  of  that  test,  which  is  a little  complicated.  [Slide  8-14],  This  is 
the  result  of  one  measured  length  of  1000  mm.  I believe  we  measured  five  total.  Plotted  on  the 
vertical  axis  is  the  measurement  uncertainty.  The  calibrated  gauge  is  actually  the  measurement 
error,  where  we  know  the  true  value.  The  black  line  represents  three  measurements  of  the  step 
gauge  in  several  different  positions,  I believe  we  measured  a total  of  43  positions.  What  is  shown 
is  vertical  offset  probe,  u and  i position  as  specified  by  the  standard.  What  is  important  is  the  red 
line,  which  is  our  uncertainty  prediction.  Our  uncertainty  prediction  was  arrived  at  by  simply 
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looking  at  the  manufacturer  specification,  six  numbers  (i.e.,  linear  displacement  errors  in  X,  Y, 
and  Z and  other  metric  performance)  which  gives  you  a simplified  measure  of  geometric  errors  of 
the  machine.  This  comes  from  the  range  of  measured  deviations  from  ballbar  measurements,  21 
positions  in  the  CMM  work  zone.  We  also  include  the  offset  probe,  which  needs  to  be  included 
since  the  form  of  the  parametric  errors  is  being  estimated.  This  approach  gives  you  a minimal 
effort  uncertainty  measure.  You  can  represent  the  area  that  has  small  measured  errors. 

We  also  decided  that  most  users  aren’t  interested  in  point  to  point  measurements  but  want  feature 
measurements.  We  used  an  aluminum,  diamond-turned  plug  gauge,  which  was  made  by  Chris 
Evans  at  NIST.  [Slide  8-15].  It  is  ground  to  a few  tenths  of  a micrometer,  which  is  perfect  for 
this  experiment.  We  measured  the  plug  gauge  using  12  symmetrically  spaced  points  and 
measured  it  36  times.  [Slide  8-16].  Then  we  changed  the  sampling  strategy.  We  still  used  12 
symmetrically  spaced  points,  but  measured  only  Vi  of  the  circle.  [Slide  8-17].  Each  time  we 
measured  the  plug  radius,  we  incremented  the  points  10°.  After  36  measurements,  we  completed 
the  entire  circle.  This  is  a graph  of  the  plug  radius.  [Slide  8-18].  Plotted  along  the  vertical  axis  is 
the  measured  radius.  Where  you  see  the  360,  1 80,  and  90,  that  is  the  angular  portion  of  the  circle 
that  was  measured  in  that  experiment.  The  first  interval  was  360  ° using  36  measurements.  What 
is  shown  in  this  blue  area  in  the  measured  data  is  a complex  structure.  It  isn’t  obvious  to  expect 
this  cyclical  behavior,  which  has  a lot  to  do  with  the  asymmetry  of  the  axis  of  the  machine.  The 
red  line  (plot  envelope)  represents  uncertainty  calculation.  We  are  satisfied  with  this  result. 

We  looked  at  the  X and  Y symmetries,  this  is  the  change  in  nominal  position  of  the  X-center  as  a 
function  of  the  sampling  strategy.  Because  the  uncertainties  were  on  the  same  order,  we  expected 
to  see  a symmetric  behavior  and  to  get  the  same  behavior  in  the  Y-center  uncertainty  that  we  saw 
in  the  X-center,  but  that  wasn’t  the  case.  [Slide  8-19].  It  had  to  do  with  the  fact  that  in  our 
machine,  the  X-axis  stacked  on  top  of  the  Y-axis,  so  there  is  an  asymmetry  in  the  kinematics 
chain.  There  is  more  variability  in  the  X measurement. 

Summarizing,  we  are  happy  with  the  results  we  obtained  from  the  simulation  by  constraints.  We 
believe  that  it  is  adaptable  to  many  different  applications.  You  have  a set  of  performance  data 
that  is  sensitive  to  all  possible  errors,  not  necessarily  just  geometrical  errors  and  may  not  all  be 
characterized.  For  a full  parametric  simulation,  the  PTB  approach  is  the  limiting  case  of 
simulation  by  constraints.  The  PTB  approach  is  very  time  intensive  and  yields  a very  small 
uncertainty.  Our  method  yields  results  very  quickly  and  the  uncertainty  is  larger,  however 
simulation  by  constraints  is  better  than  a blind  guess. 

KRULEWICH:  How  many  times  do  you  simulate  your  error  bounds?  In  the  PTB  simulation, 
what  type  of  probability  density  function  was  assumed,  normal,  uniform? 

SAWYER:  Two  hundred  machine  states  are  calculated  per  simulation.  We  have  never  gotten  a 
definitive  answer  from  PTB,  so  we  don’t  know  what  method  they  use  to  perturb  their  functions. 
He  also  uses  an  algorithm  that  limits  the  number  of  simulations  and  still  obtains  a statistically 
significant  result. 

DONMEZ:  How  did  you  determine  that  you  needed  200  machine  states  per  simulation? 

SAWYER:  Dr.  Phillips  determined  that  he  wasn’t  seeing  significant  changes  after  he  reached  a 
threshold  of  200  machine  states,  given  the  order  of  magnitude  of  errors  on  our  machine. 

DONMEZ:  Then  from  one  machine  to  another  it  might  take  a different  number  of  simulations. 
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SAWYER:  Yes.  It  only  takes  a few  minutes  to  run  a simulation. 

DONMEZ:  As  you  can  see,  there  are  areas  to  think  about  for  machine  tool  aspects.  The  principle 
itself  sounds  very  interesting  because  you  start  with  a very  limited  number  of  measurements  and 
then  calculate  uncertainties.  In  our  case,  we  can  think  about  starting  with  small  amounts  of  data 
and  then  determine  what  the  Cpk  numbers  might  be  based  upon  using  a similar  type  of  analysis. 
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We  heard  in  Vivek  Chandrasekharan’s  presentation  that  Caterpillar  is  using  NIST’s  Machine 
Tool  Classification  for  the  description  of  machine  nominal  conditions.  That  work  has  been  done 
in  another  division  at  NIST  by  Kevin  Jurrens  and  Mary  Beth  Algeo.  Unfortunately,  Kevin  could 
not  be  here  to  present  their  work,  but  he  gave  me  his  slides.  In  the  short  time  frame  that  we  have, 
I will  very  quickly  show  you  the  Machine  Classification  web  site. 

Kevin’s  project  was  called  Rapid  Response  Manufacturing,  which  means  that  they  generate 
information  models  of  different  aspects  of  manufacturing,  some  of  which  are  listed  in  this  slide. 
They  have  CAD  data,  process  planning  data,  CAM  data,  and  they  list  many  types  of  resources 
such  as  machine  tools,  cutting  tools,  tool  holders,  collets,  and  assemblies.  They  have  started  to 
develop  information  models  for  all  of  these  resources  and  ways  to  combine  those  resources  in 
electronic  formats  to  be  able  to  make  decisions  (i.e.,  process  planning,  CAD/CAM  operations, 
etc.).  I’m  really  only  interested  in  the  machine  tool  portion. 

The  web  page  that  describes  this  work  is  at  address  http://www.nist.gov/rrm.  It  describes  the 
manufacturing  resource  data  interface.  If  you  have  any  of  the  resources,  such  as  machine  tool, 
tool  assembly,  cutting  tool,  etc.,  then  you  can  develop  this  information  by  stepping  through  the 
standard  definitions  that  they  have  created.  When  I choose  machine  tool,  I am  given  some 
options.  Kevin  emphasized  that  this  has  not  been  reviewed  by  industry,  so  this  is  in  raw  form  and 
there  will  be  changes  in  these  types  of  definitions.  We  are  given  alternatives  such  as  milling 
machines,  vertical-turning  machine,  and  horizontal  turning  machine.  If  I pick  milling  machine, 
then  it  will  ask  specific  questions  about  the  product.  It  asks  how  many  axes  does  the  milling 
machine  have,  where  the  default  value  is  three.  It  also  asks  how  many  parallel  spindles  does  the 
machine  have,  how  many  separate  worktables  does  it  have,  etc..  When  you  answer  all  of  these 
questions,  then  you  are  basically  defining  your  machine  tool.  You  should  be  able  to  categorize 
the  nominal  functions  of  your  machine  and  be  able  to  electronically  store  this  information.  In  the 
last  meeting,  we  discussed  how  to  describe  the  machine  controller.  There  is  a set  of  parameters 
about  the  machine  controller.  What  we  will  do  for  the  NAMT  program  is  extract  the  relevant 
aspects  of  the  Rapid  Response  Manufacturing  project  and  incorporate  them  in  the  machine  tool 
data  repository,  similar  to  what  Vivek  presented. 
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I would  like  to  give  an  update  on  our  work  on  an  information  model  and  data  dictionary  that 
defines  information  elements  that  can  be  used  to  communicate  and  store  performance  data  of 
machine  tools.  First  I will  classify  machine  tool  performance  data,  then  discuss  the  data  we  are 
currently  modeling.  I will  explain  the  chosen  approach  to  information  modeling  and  the  structure 
and  content  of  a prototype  data  dictionary.  I will  conclude  this  presentation  with  an  example. 
There  is  still  a lot  of  work  to  be  done.  However,  I hope  that  this  presentation  will  give  you  an 
impression  of  the  goals,  methods,  and  challenges.  Obviously  this  cannot  be  an  isolated  effort  and 
we  would  welcome  a discussion  as  to  whether  this  part  of  the  project  addresses  your  needs,  if  the 
chosen  approach  is  right,  and  how  we  can  increase  your  participation. 

The  goal  of  this  NAMT  project  are  (1)  information  models  to  represent,  communicate,  and  store 
machine  tool  performance  data,  and  (2)  tools  to  improve  the  use  of  that  data.  One  such  tools  is  a 
virtual  machine,  i.e.,  an  algorithm  that  predicts  the  output  of  a machining  process  by  simulating 
the  actions  of  the  machine  tool  in  response  to  a part  program  and  the  machining  environment. 
[Slide  9-2].  Virtual  machining  promises  to  significantly  reduce  the  time  and  effort  spent  on 
prototyping  and  debugging  the  manufacturing  process.  It  will  lead  to  more  optimized  part 
designs,  process  plans,  and  resource  allocation.  The  outputs  of  a virtual  machine  in  which  we  are 
particularly  interested  are  the  tolerances  within  which  the  actual  geometry  of  the  part  will  be. 

A critical  enabler  for  virtual  machining  is  an  efficient  access  to  relevant  data  on:  the  design  of  the 
part  to  be  machined,  the  process  plan,  the  machine  tools  that  will  be  used,  tools  and  fixturing,  and 
the  machine  tool  environment.  [Slide  9-3].  Machine  tool  data  can  be  divided  into  two  categories. 
First,  data  that  applies  to  all  machines  of  a series.  Usually  this  is  design  data  published  by  the 
machine  tool  builder,  for  example,  maximum  spindle  speed,  spindle  power,  number  of  axes, 
travels,  minimum  programming  increment,  available  canned  cycles,  etc.  The  second  category  of 
data  applies  to  a specific  machine  tool.  An  important  part  of  that  data  is  the  result  of  machine 
tool  performance  tests.  I will  focus  on  that  part. 

We  envision  a layered  approach  in  the  representation  and  storage  of  machine  tool  performance 
data.  [Slide  9-4].  At  the  bottom  level,  which  is  in  red,  there  is  detailed  information  about  the 
performance  tests  and  the  equipment  that  was  used.  At  the  top  level,  there  is  summarized  data 
such  as  B5  performance  parameters  or  the  estimated  coefficients  of  error  models. 

As  an  example  consider  the  shown  performance  test  taken  from  the  draft  B5.57  standard.  This 
test  addresses  the  straightness  of  the  Z-axis  motion  of  a vertical  lathe  as  well  as  the  parallelism  of 
the  spindle  axis  with  the  Z-axis.  A straight  edge,  colored  purple,  is  mounted  on  the  spindle.  First 
the  probe  is  mounted  on  the  left  side  of  the  spindle  and  the  straightness  of  the  Z-motion  is 
measured.  Next  the  spindle  is  rotated  180  degrees.  The  measurement  surface  of  the  straight  edge 
is  now  on  the  right  hand  side.  The  probe  is  re-clamped  across  the  center  and  the  same 
straightness  measurement  is  performed.  There  are  now  two  sets  of  straightness  measurements. 
Because  of  the  straight  edge  reversal,  the  straightness  of  the  Z-axis  motion  can  be  accurately 
measured  even  if  the  straight  edge  is  not  straight.  The  difference  between  the  slope  of  the  two 
measurements  can  be  used  to  calculate  the  parallelism  error  between  the  Z-axis  motion  and  the 
spindle  axis. 
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The  lowest  layer  contains  detailed  data  about  the  experiment  such  as:  the  two  measured  signals 
(or  more  if  temperature  and  other  factors  are  recorded),  information  about  the  measurement 
equipment  that  was  used,  including  serial  numbers  and  settings,  the  measurement  setup,  the 
effective  tool  length,  information  about  the  machine  status  such  as  the  warm-up  and  exercise 
procedures,  and  finally  data  about  the  environment.  At  a higher  layer  there  is  data  that  is 
extracted  from  this  detailed  data.  In  this  example,  that  would  be  the  parallelism  error,  and 
straightness  error  data  organized  into  a column  with  Z-axis  positions  and  a column  with 
straightness  errors.  The  relevant  machine  status  would  be,  for  example,  the  length  of  the  tool  and 
the  position  of  the  machine  axes  at  the  first  point  of  measurement.  At  higher  levels,  you  might 
find  the  parameters  of  a piecewise  polynomial  fit  through  the  data,  or  B5  performance  numbers, 
such  as  one  number  for  straightness  accuracy  and  one  number  for  straightness  repeatability.  At 
higher  levels  you  will  also  find  data  extracted  from  a combination  of  tests,  such  as  the 
coefficients  of  the  full  error  model  of  a machine.  During  this  presentation,  I would  like  to  address 
the  most  challenging  data:  those  in  the  lowest  layer. 

During  the  first  step  of  the  information  modeling  process  we  use  a tool  called  a data  dictionary 
[Slide  9-5].  The  purpose  of  this  tool  is  to  provide  the  names,  definitions,  and  relations  of  the  data 
elements  that  can  be  retrieved  from  a database  of  machine  tool  performance  data.  It  does  not 
have  the  formalism  of  an  EXPRESS  model  but  we  think  it  can  be  translated  into  one.  The  focus 
of  the  data  dictionary  differs  from  the  classical  data  dictionary,  which  addresses  the  structure  of  a 
database.  The  dictionary  discussed  here  tries  to  define  the  information  that  can  be  retrieved  from 
and  stored  into  a database,  not  how  this  information  is  stored  internally.  On  the  right  hand  side  of 
the  slide  you  see  an  illustration  of  this  concept,  which  will  be  actually  demonstrated  during  the 
next  presentation.  A user  asks  a question  about  a machine.  Analysis  software,  before,  after,  or  on 
both  sides  of  the  Internet,  processes  the  question  and  may  decide  that  machine  tool  data  is  needed 
to  generate  an  answer.  The  software  formulates  a query  to  the  database,  the  data  is  retrieved, 
processed  by  the  analysis  software,  and  an  answer  is  returned.  What  we  would  like  to  address  is 
the  interface  between  the  analysis  software  and  the  database. 

There  are  two  different  approaches  to  data  modeling.  The  first  is  a top  down  approach.  It  tries  to 
anticipate  the  queries  that  will  be  made  of  the  database.  The  second  is  bottom  up.  It  tries  to 
assess  which  information  elements  fully  describe  a particular  performance  evaluation  test, 
without  trying  to  predict  the  possible  use  of  that  data.  Our  focus  is  on  the  latter  approach. 
Analysis  of  performance  evaluation  data  is  an  evolving  field.  Applications  for  machine  tool 
performance  data  are  being  developed  that  were  not  anticipated  five  years  ago.  Therefore  we  try 
to  develop  the  data  dictionary  in  such  a way  that  captures  the  intrinsic  information  of  a test 
without  linking  it  to  the  possible  use  of  the  test  results. 

There  exists  a variety  of  software  packages  for  the  performance  evaluation  of  machine  tools. 

[Slide  9-6].  Many  of  these  are  made  by  the  manufacturer  of  a measurement  device,  such  as  a ball 
bar,  and  tailored  to  that  particular  instrument.  Why  can't  we  store  and  communicate  performance 
data  using  the  file  formats  employed  by  these  packages?  First,  different  data  models  and  formats 
are  used  even  for  similar  measurement  instruments  and  tests.  Second,  sometimes  the  formats  are 
proprietary  and  the  data  may  be  hidden  in  a binary  file  whose  content  can  only  be  retrieved  by  the 
software  in  a form  dictated  by  the  software.  Third,  most  formats  are  tailored  towards  a specific 
type  of  performance  test  and  may  not  be  adequate  for  tests  not  found  in  the  standards,  or  recently 
standardized  tests.  Finally,  and  most  important,  not  all  the  data  relevant  to  a particular  test  is 
stored.  Usually  the  stored  data  is  limited  to  the  information  required  to  produce  the  graphs  and 
performance  parameters  specified  in  current  machine  tool  standards.  For  example,  the  effective 
tool  offset  or  location  of  the  test  in  the  machine  workspace  is  rarely  stored.  Such  information  is 
essential  for  error  modeling  purposes  and  to  combine  or  compare  the  results  of  different  tests.  In 
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practice  this  information  is  often  lost  or  entered  in  notebooks  with  a life  different  from  the  data 
files. 

Our  goals  are  a unified  information  model  and  associated  data  format  that  will  allow  a 
straightforward  interchange  and  storage  of  all  relevant  information  about  a test.  It  should  allow 
for  the  reconstruction  of  the  nature  of  the  test,  who  did  it,  when  it  was  done,  and  why. 

[Slide  9-7].  The  used  equipment  and  respective  settings  should  be  identified.  We  hope  to  be  able 
to  reconstruct  essential  information  about  the  setup,  measurement  procedure,  machine  status, 
machine  motion,  and  environmental  conditions. 

We  will  focus  on  standardized  tests,  but  we  hope  that  the  developed  data  dictionary  and 
associated  information  models  can  also  be  used  for  special  tests.  The  models  should  not  enforce 
the  storage  of  all  information,  but  provide  standardized  possibilities  to  do  so.  The  modeled 
information  has  to  encompass  the  information  currently  stored  by  the  major  data  acquisition 
packages  (e.g.,  Renishaw,  API,  HP,  Heidenhain,  etc.).  It  should  allow  for  an  efficient  handling  of 
queries  and  will  be  translated  into  an  EXPRESS  model. 

This  slide  gives  an  indication  of  the  information  elements  that  can  be  used  to  describe  test 
equipment.  [Slide  9-8].  Examples  are  the  manufacturer  of  the  equipment,  the  model  number,  the 
ID  number,  the  settings  of  the  equipment  during  the  test,  the  type  of  compensations  that  were 
applied,  how  many  samples  were  averaged,  the  applied  filters  etc.  The  software  that  was  used 
with  the  equipment  should  be  known  including  its  version  number.  If  artifacts  are  used,  their 
important  properties,  such  as  the  effective  coefficient  of  expansion,  have  to  be  stored. 

I would  like  to  stress  that  the  data  dictionary  is  still  being  developed  and  that  your  participation  in 
this  process  is  crucial.  The  dictionary  consists  of  two  parts  [Slide  9-11].  The  first  part  is  a master 
list  of  entities  that  you  can  use  to  describe  the  performance  test.  The  second  part  is  essentially  a 
user  guide.  Given  the  nature  of  the  test,  e.g.,  a circular  contouring  tests  involving  two  machine 
axes  and  using  a ballbar  whose  length  is  unknown,  it  provides  a list  with  the  entities  that  can  be 
used  to  describe  that  test. 

There  are  currently  two  Web  pages  at  the  NIST  site:  one  pertaining  to  workshops  and  associated 
documents  and  another  to  the  experimental  data  repository  that  Larry  will  talk  about  next.  On  the 
first  web  page  you  see  a link  to  the  data  dictionary.  If  you  click  on  this,  a database  with  the 
current  master  list  of  attributes  will  be  downloaded  to  your  computer.  You  can  only  read  the  file 
if  you  have  MS  Access  97.  We  will  be  working  on  a web  page  that  does  not  depend  on  Access. 

On  this  slide  you  see  the  most  important  form  of  this  database.  You  can  interpret  it  as  an  index 
card  with  the  definition  and  possible  specifications  of  an  entity.  In  this  particular  example  you 
see  the  entity  approach_direction.  It  can  be  specified  in  two  ways.  The  first  specification, 
indicated  by  the  identification  number  1,  is  an  enumeration.  This  specification  is  used  when  the 
test  involves  an  ordered  succession  of  target  points,  e.g.,  the  positioning  accuracy  test  of  an  axis. 
The  first  enumeration  item  describes  the  case  where  all  target  points  are  approached  from  a 
negative  direction.  The  second  enumeration  item  describes  the  case  where  each  target  point  is 
approached  in  two  directions,  first  negative  and  then  positive,  before  proceeding  to  the  next  target 
point.  Each  enumeration  item  has  its  own  form  with  the  appropriate  definition.  The  second 
specification  specifies  the  approach  direction  as  a vector  in  the  machine  axis  space.  As  stated, 
this  list  of  entities  is  under  development  and  changing.  For  easy  interpretation  you  need  the 
graphical  schemas  that  are  being  developed  in  the  second  part  of  the  data  dictionary. 
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For  the  second  part  of  the  data  dictionary  we  are  developing  a tree  structure.  It  will  provide  a list 
of  the  relevant  entities  given  the  properties  of  the  test  and  the  used  equipment.  The  challenge  that 
we  are  encountering  is  a large  variety  of  tests  for  machine  tools  as  well  as  measurement 
equipment  used  for  those  tests.  I have  tried  to  give  an  impression  of  this  variety  for  the  case  of  a 
circular  contouring  test.  In  this  diagram  a vertical  line  connects  the  properties  that  apply  [Slide  9- 
11].  Diagonal  lines  are  branches  and  are  used  to  indicate  the  different  instances  for  a particular 
property. 

A circular  contouring  test  can  be  performed  using  a ball  bar,  a circular  disk,  or  a grid-plate.  A 
circular  disk  is  a circular  reference  artifact.  A 2-D  probe  is  used  to  measure  errors  in  the  circular 
path  of  the  tool  holder  relative  to  the  disk.  The  grid-plate  was  introduced  a few  years  ago.  It  is  a 
2D  scale  that  is  used  to  measure  the  position  of  the  tool  holder  in  two  dimensions.  The  nature  of 
the  measurement  data  obtained  during  the  test  depends  on  the  type  of  measurement  device.  The 
ball  bar  measures  changes  in  the  radius  of  the  circular  path.  It  is  implied  that  the  contouring 
speed  is  constant.  Thus  one  can  deduce  the  angular  position  of  the  ball  bar  from  the  sequence 
number  of  a measured  value.  A grid  plate  measures  the  X and  Y coordinates  of  the  tool  holder. 
These  can  be  translated  into  an  angle  and  a radius. 

A circular  test  can  be  performed  either  statically  or  dynamically.  During  the  static  test  the 
machine  is  moved  to  a target  point,  the  machine  motion  is  halted,  a measurement  is  taken,  and  the 
machine  is  moved  to  the  next  target  point.  During  the  dynamic  test  measurements  are  taken  when 
the  machine  is  moving.  This  mode  is  used  most  often.  Different  properties  are  applicable  to 
static  and  dynamic  tests.  For  example,  during  a static  test  a reported  measurement  value  may  be 
the  average  of  a certain  number  of  samples.  Also  the  properties  of  the  used  trigger  to  initiate 
sampling  differ  and  may  be  important. 

The  machine  motion  for  the  dynamic  test  can  be  programmed  in  two  different  ways.  When  G02 
or  G03  codes  are  applied  the  circular  interpolation  capability  of  the  machine  is  used  to  generate 
circular  motion.  As  suggested  in  e.g.  the  recent  ASME  B5.57  standard  for  lathes,  you  can  also 
perform  the  dynamic  test  using  a large  number  of  small  linear  movements,  i.e.  a part  program 
with  G01  codes.  This  can  provide  insight  into  the  controller's  capability  to  handle  high  data 
densities  (e.g.,  to  see  whether  data  starvation  occurs  and  its  effect).  A different  set  of  parameters 
applies  to  describe  a test  with  G01  or  G02/G03  codes. 

If  we  limit  our  further  discussion  to  ball  bar  measurements  there  are  several  options  to  consider. 
First,  the  ball  bar  can  have  an  uncalibrated  length  (you  don’t  know  what  its  true  length  is),  a 
calibrated  length  (you  know  the  absolute  length),  or  its  length  can  be  determined  using  a so-called 
calibrator.  A calibrator  is  a reference  artifact  that  incorporates  one  or  more  known  lengths. 
Placing  the  ball  bar  into  this  reference  allows  the  software  to  compute  its  true  length.  Again  the 
applicable  entities  differ.  For  example,  in  the  case  of  a calibrator,  the  ID  number  of  the  reference 
artifact  might  be  important. 

A second  option  to  consider  is  the  method  used  to  align  the  center  of  the  ball  bar.  Often  a 
kinematic  alignment  is  used.  Here  the  tool  is  moved  to  the  center  of  the  circular  path.  The 
position  of  the  center  sphere  is  then  adjusted  such  that  it  contacts  the  tool  socket  in  a 
kinematically  well-defined  way.  Other  alignment  techniques  are  available.  The  B5.54  standard 
describes  the  quadrant  method.  Here  the  ball  bar  is  successively  placed  along  the  coordinate 
directions.  The  center  of  the  circular  path  is  adjusted  such  that  the  average  of  the  ball  bar 
readings  equals  zero.  Another  alternative  is  to  use  the  machine  probe  to  assess  the  coordinates  of 
the  center  sphere. 
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Third,  the  ballbar  can  be  in  the  plane  of  the  circular  path  or  it  can  be  inclined  relative  to  this 
plane.  Finally,  if  the  machine  has  one  or  more  rotary  axes,  a variety  of  tests  are  possible  that 
involves  movement  of  these  axes.  Examples  of  such  tests  can  be  found  in  the  Appendix  of  the 
B5.54  standard.  If  the  machine  has  a rotary  table,  the  table  can  rotate  during  the  test  such  that  the 
table  socket  chases  the  tool  socket.  The  entities  that  describe  this  test  are  obviously  different 
from  the  classical  circular  contouring  test  that  involves  movement  of  only  two  linear  machine 
axes. 

I hope  that  this  diagram  gives  you  an  impression  of  the  challenge  that  we  are  facing  in  trying  to 
define  information  models  for  the  large  variety  of  performance  evaluation  tests  and  measurement 
equipment,  even  if  we  limit  ourselves  to  those  that  are  described  in  the  standards. 

I would  like  to  conclude  this  presentation  with  an  example:  the  measurement  of  the  positioning 
accuracy  of  a linear  axis  using  a laser  interferometer.  [Slide  9-13].  In  the  next  slides  I will  show 
the  relevant  entities  and  their  relations.  Note  that  the  various  groups  do  not  necessarily 
correspond  to  tables  in  a database.  Our  focus  is  on  what  information  can  be  extracted  from  a 
database,  not  how  it  is  organized  internally. 

The  first  entity  contains  general  information  about  the  test.  It  helps  you  to  quickly  identify  what 
the  test  was  about.  In  this  case  the  test  addresses  a single  axis,  the  Z-axis.  The  test  was 
performed  as  part  of  a machine  acceptance  procedure.  The  default  unit  system  is  metric.  In  the 
data  dictionary  you  can  see  that  this  implies  that,  for  example,  temperatures  are  always  in  degrees 
C unless  otherwise  specified.  Units  are  challenging,  and  their  use  in  the  data  dictionary  still 
needs  refinement. 

The  next  entity  contains  information  about  the  standard  that  describes  the  test.  Like  many  entities 
it  has  a unique  identification  number  which  can  be  used  to  refer  to  it.  The  standards  entity 
contains  information  about  the  standards  organization,  the  number  and  name  of  the  standard,  the 
name  of  the  test  in  the  standard,  the  respective  section  number,  as  well  as  the  date  when  the 
standard  was  published.  In  a database  an  entity  like  this  would  probably  be  organized  into  two  or 
more  tables,  e.g.,  one  table  with  standards  and  another  table  with  various  sections  of  standards 
with  pointers  to  the  previous  table. 

The  next  entities  contain  information  about  the  machine,  the  operator,  and  the  machine  status 
during  the  test.  [Slide  9-14].  For  example,  the  C-axis,  which  is  the  spindle  axis,  was  clamped 
during  the  test,  the  software  compensation  of  the  machine  was  active,  and  the  coolant  was  off. 

The  machine  was  warmed-up  by  turning  on  the  servos  for  two  hours  prior  to  measurement.  Of 
course  here  we  have  to  compromise  between  ease-of-use  and  level  of  detail.  Coolant,  for 
example,  can  be  applied  in  many  different  ways.  Currently  we  have  only  implemented  an  on/off 
state. 

Next  you  see  information  about  the  data  acquisition  software.  [Slide  9-15].  The 
manufacturer_ID  entry  is  a unique  identification  number  that  points  to  more  extensive 
information  about  the  manufacturer,  such  as  address  and  contacts.  The  trigger  entity  contains 
information  about  the  mechanism  used  to  trigger  a measurement.  In  this  case  the  software  looks 
at  the  laser  reading.  When  the  reading  is  close  to  the  target  value  it  waits  for  a specified  amount 
of  time  and  takes  a measurement.  This  mode  is  indicated  by  the  trigger_target  value  for  the 
trigger_mode  entity.  The  target_window  entity  is  the  width  of  the  zone  centered  on  the  target 
within  which  the  signal  has  to  be  for  a specified  time  before  measurement  is  triggered.  The 
respective  delay  is  specified  by  the  trigger_dwell  entity.  The  identification  number  of  the  sensor 
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that  is  being  used  as  a trigger  is  denoted  as  SE_1.  Later  we  will  see  that  this  sensor  is  a laser 
interferometer  in  distance  mode. 

On  this  slide  you  see  some  sensor  definitions.  [Slide  9-16].  The  first  sensor  measures  air 
pressure.  We  will  see  that  this  sensor  is  used  to  compensate  the  laser  interferometer  reading.  The 
next  sensor  is  used  to  measure  the  temperature  of  the  machine  scale.  This  sensor  will  also  be 
used  to  adjust  the  reading  of  the  laser  interferometer  to  compensate  for  the  thermal  expansion  of 
the  scale.  The  sensor  is  indeed  a temperature  sensor,  it  measures  temperature  by  sensing  changes 
in  resistance,  its  resolution  is  0.01  degrees  C,  and  it  is  located  near  the  Z-scale  of  the  machine. 
There  is  still  some  work  to  be  done  on  how  to  specify  the  location  of  sensors.  Note  that  the 
sensor  entity  contains  an  entry  for  the  identification  number  of  the  readout,  which  points  to  more 
information  about  that  readout. 

This  main  sensor  is  of  course  the  laser  interferometer  itself.  [Slide  9-17].  The  measurand  is 
displacement.  The  sample  average  entry  is  20,  which  means  that  each  recorded  measurement 
value  equals  the  average  of  20  samples.  These  samples  are  measured  with  a frequency  of  1 0 Hz. 
The  sensor  is  connected  to  the  same  readout  as  the  previous  sensors.  The  sensor  uses  a trigger 
that  we  have  already  defined.  The  sensor_direction  entry  indicates  that  a positive  measurement 
value  equals  the  displacement  of  the  target  when  the  machine  moves  in  positive  Z-direction.  The 
target,  the  retro-reflector,  is  connected  to  the  second  turret  of  the  machine.  The  reference,  the 
interferometer,  is  connected  to  the  spindle  axis.  The  sensor_datum_when  entry  indicates  when 
the  sensor  datumed.  In  this  case  the  sensor  is  datumed  at  the  beginning  of  the  first  run  as  opposed 
to  at  the  beginning  of  each  run.  An  important  entry  is  the  effective  tool  vector  that  describes  the 
position  of  the  retro  reflector.  The  effective  tool  vector,  together  with  the  position  of  the  machine 
axes,  defines  the  position  of  the  measurement  line,  as  discussed  this  morning  in  the  LLNL 
presentation.  A laser  interferometer  usually  does  not  record  the  raw  measurement  values.  The 
measurements  have  been  compensated  in  some  way.  In  this  case  they  have  been  compensated  for 
the  velocity  of  light  in  air  and  the  thermal  expansion  of  the  machine  scale.  The  used  sensors  for 
air  pressure,  air  humidity,  air  temperature,  and  material  temperature  are  indicated,  as  is  the  used 
coefficient  of  thermal  expansion.  The  compensation  did  not  address  the  dead  path  length  of  the 
setup. 

The  next  entry  defines  how  the  machine  moved  during  the  measurements.  [Slide  9-17].  The 
measurements  are  performed  in  a static  mode,  i.e.,  the  machine  motion  stops  before  a 
measurement  value  is  taken.  In  between  target  points  the  machine  has  a programmed  feed  rate  of 
2000  mm/min.  The  targets  are  on  a line  parallel  to  the  Z-axis  of  the  machine.  When  the  machine 
axes  are  at  the  coordinates  indicated  by  the  target_line_start  entry  the  target  is  at  the  start  point  of 
the  measurement  line.  The  individual  target  points  are  specified  as  a table  of  target  numbers  and 
distances  relative  to  the  start  point.  In  order  to  avoid  the  aliasing  effect  that  we  saw  this  morning, 
the  targets  are  located  at  random  positions  along  the  Z-axis. 

Now  that  we  have  defined  the  purpose  of  the  test,  the  used  machine  tool  standard,  the  machine, 
the  status  of  the  machine,  the  various  sensors,  readouts  and  triggers,  we  can  finally  specify  the 
measurement  data.  [Slide  9-19].  The  data  is  organized  into  runs.  The  approach  direction  for  the 
first  run  is  indicated  as  pilgrim_positive.  As  discussed  this  implies  that  each  target  point  is 
approached  in  two  directions,  first  positive  and  then  negative,  before  proceeding  to  the  next  target 
point.  Next,  we  see  a table  with  measurement  data  as  well  as  entries  that  define  how  this  table  is 
organized.  Finally  there  are  entries  that  summarize  sensor  data  taken  during  the  run,  in  this  case 
the  maximum,  minimum,  and  average  temperatures  measured  by  three  sensors. 
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This  concludes  the  example.  You  can  find  the  terms  that  I used  in  this  example  in  the  data 
dictionary.  I hope  that  this  example  and  the  rest  of  the  presentation  gave  you  an  impression  of 
complexity  of  the  information  that  we  are  trying  to  model  as  well  as  the  chosen  approach.  I’d 
like  to  open  up  for  discussion.  [Slide  9-23]. 

KATTER:  Why  did  you  use  the  key  word  approachjpilgrim_positive  instead  of  just  “positive” 
for  your  approach  direction? 

SOONS:  This  is  an  enumeration  item  that  we  defined  to  have  a certain  meaning.  It  is  one  of  the 
four  options  of  the  approach  direction  entity.  It  implies  that  each  target  point  is  approached  in 
two  directions,  first  positive  and  then  negative,  before  proceeding  to  the  next  target  point.  Use  of 
this  entry  avoids  the  indication  of  the  approach  direction  for  each  individual  target  point. 
However,  the  data  dictionary  does  provide  means  to  specify  the  approach  direction  for  each  target 
point  by  placing  in  the  data  table  a “+”  for  positive  approach  direction  and  for  negative 
approach  direction. 

WELSCH:  What  tends  to  happen  in  systems  discussions,  is  that  terms  get  longer  as  you  add  more 
adjectives  and  definitions  get  longer  as  you  add  more  specifics.  The  adjectives  allow  for  concise 
definitions  of  key  words.  In  a regular  dictionary  you  may  have  several  definitions  for  one  word, 
we  want  one  definition  for  each  key  word. 

SOONS:  At  this  stage  we  have  not  yet  spend  much  time  on  a systematic  and  more  optimized 
naming  scheme  for  items  in  the  dictionary. 

CHANDRASEKHARAN:  Is  this  schema  what  the  EXPRESS  language  outputs? 

DONMEZ:  The  EXPRESS  models  are  being  worked  on,  but  aren’t  presented  today. 

SOONS:  This  slide  shows  other  topics  about  which  we  would  like  some  feedback.  [Slide  9-23]. 
One  item  is  the  focus  of  our  effort,  especially  if  the  presented  level  of  detail  is  desired.  As  I said 
before,  we  are  making  our  life  difficult  in  trying  to  model  the  lowest  tier  of  data.  It  requires  a lot 
of  detail  when  trying  to  capture  everything  that  occurred  during  a performance  evaluation  test. 
Perhaps  we  should  concentrate  on  higher  levels.  For  example,  in  case  of  a circular  contouring 
measurement,  the  main  data  is  a table  with  angle  versus  error.  Another  area  of  discussion  is 
whether  to  tie  the  data  dictionary  closer  to  the  design  of  a database.  It  probably  would  ease  the 
information  modeling  and  make  the  dictionary  easier  to  apply.  On  the  other  hand,  we  may  also 
want  to  link  the  definitions  more  closely  to  existing  file  formats.  Another  item  is  whether  we 
should  restrict  ourselves  to  the  performance  tests  and  measurement  equipment  described  in 
existing  standards  or  if  we  should  also  try  to  capture  more  exotic  tests  and  instruments.  We 
would  also  like  some  feedback  on  the  approach  that  you  are  taking  to  information  modeling  of 
performance  data.  We  would  appreciate  comments  about  the  organization  of  the  items  in  the  data 
dictionary.  Finally  we  would  like  to  discuss  how  to  increase  participation  and  when. 

COVINGTON:  I think  that  we  should  stick  to  standardized  tests.  I think  that  we  need  to  draw  a 
line  somewhere,  because  there  are  too  many  tests  out  there  to  try  and  capture  all  of  them. 

SOONS:  To  follow  up  on  that,  in  the  current  B5.54  standard  for  machining  centers  there  are  some 
unusual  tests  in  the  appendix.  Would  you  say  leave  out  the  tests  in  the  appendix  as  well? 

COVINGTON:  I would  say  incorporate  the  standard  tests  first,  then  the  tests  in  the  appendix. 


48 


SOONS:  I did  get  the  opportunity  to  visit  a Boeing  plant  where  I saw  that  they  were  using  one  of 
the  ball  bar  tests,  outlined  in  the  appendix,  which  involves  a rotary  table.  Are  you  currently 
including  that  test  in  your  database? 

COVINGTON:  Yes. 

KRULEWICH:  Are  you  defining  a database,  or  just  a standard  language  that  someone  else  can 
use  to  develop  the  database. 

SOONS:  I believe  there  is  more  than  one  application.  What  I showed  you  here,  basically  at  the 
interface  between  database  and  application,  can  be  interpreted  as  a language  or  data  format.  On 
the  other  hand,  we  are  also  trying  to  use  the  definitions  to  develop  a database  by  translating  the 
dictionary  into  an  EXPRESS  schema.  We  are  experimenting  with  a prototype  repository,  which 
Larry  will  show  you.  However,  the  first  step  is  to  catalog  the  information  involved.  That  is  the 
main  goal. 

KRULEWICH:  I don’t  have  much  experience  with  databases,  so  if  Boeing  performed  some 
specialized  tests,  how  difficult  would  it  be  to  add  one  more  test  to  the  repository? 

WELSCH:  It  would  be  nice  if  the  repository  were  extensible. 

KRULEWICH:  So  the  user  can  add  one  more  tests  to  the  repository. 

COVINGTON:  I think  we  should  start  small  and  get  a functional  repository  and  then  expand  to 
other  tests  in  the  future. 

SOONS:  One  of  the  reasons  that  this  data  dictionary  has  more  complex  definitions  is  because  of 
the  extensibility.  We  want  to  use  a few  words  to  describe  a large  variety  of  tests  and  equipment. 

COVINGTON:  Could  you  explain  EXPRESS  in  more  detail? 

SOONS:  I am  not  an  expert  in  this  area.  Has  anyone  successfully  used  data  modeling  tools  in  this 
area?  One  of  the  challenges  that  we  have  encountered  is  the  large  variety  of  properties  that  are  not 
mutually  exclusive,  which  makes  the  tree  very  wide. 

CHANDRASEKJHLARAN:  We  downloaded  the  database  and  found  that  it  works  O.K.  The 
second  thing  is  that  the  road  map  should  define  the  level  of  detail  that  you  want  to  get  to.  One 
thing  that  we  would  like  is  the  capability  to  download  data  from  the  repository  for  our  specific 
applications.  Right  now  we  only  have  the  capability  to  upload  data.  Until  we  have  application 
tools  that  will  enable  us  to  manipulate  data,  we  need  to  stay  closer  to  existing  file  formats  so  that 
we  can  continue  to  use  the  existing  software  packages  (i.e.,  Renishaw,  API,  etc.)  for  data  analysis. 

DONMEZ:  Do  you  think  people  on  the  shop  floor  can  provide  data  in  the  level  of  detail  that 
we’ve  talked  about  here? 

COVINGTON:  I looked  at  the  list  and  saw  that  it  was  very  comprehensive  and  well  done.  But 
no,  the  shop  floor  can’t  provide  that  level  of  detail.  What  we  try  to  do  is  to  keep  a log  file  where 
all  the  parameters  are  provided  for  tests  that  have  been  pre-defined.  The  user  can  change  certain 
parameters  for  a specific  test,  but  doesn’t  have  to  enter  redundant  information  every  time. 
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CHANDRA SEKHARAN:  Same  with  our  shop  tests.  All  data  gets  loaded  in  automatically,  but 
the  user  will  change  certain  fields  such  as  when  the  last  calibration  was  performed,  etc..  The 
problem  is  that  this  procedure  may  vary  from  shop  to  shop. 

DONMEZ:  Could  we  collect  from  Boeing  and  Caterpillar  the  log  files  that  you  keep  for  your 
internal  use  to  give  us  a better  idea  of  what  information  you  are  looking  to  store  in  the  repository? 

CHANDRA  SEKHARAN:  We  can  help  you  develop  the  templates,  but  we’ll  have  to  work 
towards  sharing  the  templates  at  least  within  the  CRADA. 

DONMEZ:  It  seems  like  most  of  the  information  is  generic  and  there  shouldn’t  be  too  much 
proprietary  information. 

DAHILIG:  Back  to  the  question  on  whether  or  not  we  should  be  linked  closer  to  the  database 
design.  It  seems  the  attributes  of  the  tests  and  the  machine  data  are  specific  data.  Each  company 
will  have  different  uses  for  the  data  and  have  their  own  tests  with  their  own  set  of  attributes.  I 
think  that  we  should  concentrate  on  creating  a database  that  is  generic/standard  (i.e.,  for  the  ball 
bar),  but  where  each  company  will  have  their  own  unique  fields  to  add. 

HEMMERLE:  In  your  data,  when  you  for  example  perform  Z-axis  laser  measurements,  is  that  as 
you  find  the  machine,  compensations  not  active,  or  after  you  compensate  the  data? 

SOONS:  Under  the  entities  for  machine  status,  you  will  find  an  entity  that  states  whether  the 
compensation  was  ON  or  OFF.  It  doesn’t  say  what  types  of  compensations  were  active,  though. 

It  is  your  choice. 

HEMMERLE:  On  our  machines,  we  keep  track  of  the  raw  data  and  the  compensated  data. 

SOONS:  Some  people  may  want  to  keep  track  of  which  compensations  were  active,  and  the 
details  of  the  compensation.  Do  we  want  to  go  into  more  detail  than  ON  or  OFF? 

DONMEZ:  With  ON  or  OFF  representation,  could  we  capture,  say,  90%  of  the  data?  When  the 
machine  starts  with  some  exotic  type  of  compensation,  then  maybe  we  want  to  note  that.  We 
have  to  keep  our  scope  somewhat  limited  so  that  we  can  produce  a repository  in  a reasonable  time 
frame. 

COVINGTON:  We  need  to  get  something  useful  in  a short  time  frame,  say  1-2  year  time  frame. 
We  are  running  into  funding  issues  and  have  to  show  some  progress  to  our  management. 

DAHILIG:  As  part  of  the  project  plan,  while  we  are  sharing  information  with  this  group,  we 
would  like  to  see  a standard  repository  with  analysis  tools.  Our  management  is  looking  for  a 
return  on  their  investment. 

COVINGTON:  We  could  put  more  people  on  this  project  and  have  greater  visibility.  We  could 
try  and  have  a link  to  the  MCDRS  site. 

KRULEWICH:  Is  your  database  functioning  on  the  web? 

WELSCH:  Not  at  this  time.  We  are  still  in  the  experimental  stage.  The  repository  is  not  fully 
implemented  at  this  time. 


50 


Data  Repository 
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National  Institute  of  Standards  & Technology 

This  presentation  is  made  from  more  of  a programming  perspective  than  from  a machine  tool 
perspective.  I’m  doing  this  presentation,  but  Hans  has  probably  done  more  work  on  this 
repository  than  I have.  Neil  Wilkin  from  NIST  is  key  to  the  pages  incorporated  in  the  repository. 

I want  to  present  a framework  for  talking  about  issues.  [Slide  10-2].  I will  present  where  we  were 
at  the  last  workshop,  where  we  are  today,  and  where  I want  to  be  tomorrow  (Jan.-Feb.  where  we 
will  achieve  more  stability  where  data  will  be  more  maintained  than  it  is  now).  I will  also  talk 
about  where  I want  to  be  the  day  after  tomorrow,  I’m  not  sure  of  the  time  frame  here.  There  are 
certain  things  that  we  are  encountering,  i.e.,  firewalls,  that  tend  to  blur  the  vision. 

When  I speak  about  platform,  I’m  speaking  about  the  operating  environment:  hardware, 
software,  and  the  things  that  I expect  to  have  on  the  machine.  [Slide  10-3].  CGI  scripting  tools: 
CGI  is  the  common  gateway  interface,  which  is  mostly  performed  at  the  back  end  of  the  Web 
server.  CGI  is  the  way  you  get  to  the  back  end  of  the  Web  server,  and  there  is  a set  of  scripting 
tools  for  doing  that.  Analysis  tools  give  us  the  graphs,  and  Hans  mentioned  this  in  his 
presentation,  where  he  was  saying  that  the  query  goes  into  the  database  through  analysis  tools, 
but  we  also  will  go  through  analysis  tools  coming  back  the  other  way. 

When  I started  with  the  repository,  I was  running  on  a fairly  small  system  with  small  disks  and 
was  running  on  Netscape  fastback  server  under  Windows  NT,  Pentium  200,  with  slow  disk 
access.  [Slide  10-4].  Everything  was  fairly  portable  to/from  NT  to  UNIX  and  we  could  use  a 
common  set  of  tools.  The  exception  there  in  terms  of  portability,  is  related  in  the  file  name 
extensions.  This  is  a UNIX  shell  or  user  interface  dating  back  to  the  days  when  terminals  were 
ASCII  and  we  didn’t  have  graphics,  called  the  Korn  shell  (Kshell).  We  are  also  using,  fairly 
extensively,  the  Perl  language,  which  is  the  new  language  for  managing  text,  where  text  is  both 
coming  into  and  flowing  out  of  the  repository.  This  is  the  language  of  choice  for  the  back  end. 
Analysis  is  being  done  with  MATLAB.  We  were  doing  stream  search  linearly  through  all  the 
files  in  the  repository,  which  was  very  slow.  The  design  was  what  I would  call  a classic  web 
methodology  with  one  exception  of  the  MATLAB  performing  analysis.  The  big  change  in  the 
platform  is  that  we  went  to  high-speed  disks  that  have  a tremendous  impact  on  performance. 

[Slide  10-5].  We  also  moved  to  a dual  processor  system,  and  are  not  running  NT  server.  We 
have  also  moved  from  the  Netscape  FastTrack  server,  to  the  Enterprise  server.  That  is  the 
environment  in  which  the  database  is  incorporated. 

Portability  Today.  We  are  now  limited  to  the  NT  platform  because  of  DDE,  dynamic  data 
exchange,  which  we  are  using  very  heavily.  This  is  a Microsoft  method  of  exchanging  data, 
which  we  are  using  to  communicate  from  the  web  to  MATLAB.  MATLAB  is  used  in  the 
analysis,  but  also  is  currently  used  as  the  database.  Basically,  the  database  is  just  a bunch  of 
vectors  that  get  loaded  into  MATLAB,  messaged,  and  then  displayed  on  the  Web  in  the  form  of  a 
graph.  This  is  faster  than  the  method  we  were  using,  but  will  not  be  used  in  the  next  stage.  The 
user  interface  will  talk  to  Perl,  Kshell,  CGI,  MATLAB,  and  then  the  data  comes  back  through 
MATLAB  for  calculation.  MATLAB  is  the  central  engine. 

We  will  go  through  the  demo  at  this  time  at  the  NIST  Machine  Tool  Data  Repository  site.  We 
will  go  to  the  machining  centers  page,  go  to  vertical  machining,  machine  A,  then  submit  data. 

We  have  a table  of  possible  tests  for  machine  tool  performance,  but  there  are  only  two  operations 
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that  are  functional.  When  we  submit  data,  we  are  submitting  a call  to  MATLAB,  which  is 
generating  a page  dynamically.  This  is  a form  that  is  generated  each  time  by  MATLAB.  When 
you  submit  data,  no  matter  what  name  you  input  for  the  machine,  the  software  will  encode  this 
name.  For  example,  if  there  are  currently  Machine  1,  Machine  2, ...,  Machine  8,  then  the  next 
machine  you  input,  if  not  matching  the  current  machines  will  be  encoded  as  Machine  9.  If  you 
resubmit  data  for  that  machine,  you  have  to  use  the  name  Machine  9.  After  the  data  is  submitted, 
the  data  first  encounters  a Kshell  script  (Perl  couldn’t  handle  all  of  the  data  in  the  initial  design), 
messaged  by  Kshell,  then  messaged  by  Perl,  then  encounters  MATLAB  which  incorporates  the 
new  file  into  the  database  and  generates  the  form  stating  that  it  the  file  has  been  incorporated  into 
the  database.  Now  we  will  return  to  the  machining  centers  page  go  to  vertical  machining, 
machine  A and  go  to  the  analysis  side.  The  analysis  graph  is  generated  dynamically. 

SOONS:  We  have  one  sample  database  in  MATLAB  format,  which  contains  the  Renishaw 
header  information:  operator,  machine,  etc.,  the  data  is  stored  in  ASCII  files. 

Tomorrow:  I don’t  expect  the  platform  to  undergo  any  changes.  [Slide  10-6].  I expect  to  be 
adding  Microsoft  ODBC,  which  is  an  open  standard,  but  isn’t  called  ODBC  in  the  standard.  I 
expect  the  analysis  package  to  remain  as  MATLAB.  I expect  to  merge  the  database  to  Microsoft 
SQL  server,  which  is  the  first  software  that  passed  all  of  the  SQL  certification  tests  that  NIST 
formulated  for  passing  SQL  servers.  I’m  told  that  from  the  people  in  the  SQL  group  at  NIST  who 
perform  the  testing.  Perl  is  free  and  available  off  the  Web,  yet  available  commercially.  I 
downloaded  the  ODBC  interface  for  Perl  from  the  Web  as  well.  The  database  that  I intend  to 
initially  build  in  the  February  timeframe  will  capture  the  lowest  level  that  is  captured  with  the 
ballbar  data. 

The  Day  after  Tomorrow.  [Slide  10-7].  I believe  that  we  are  going  to  move  to  a design  that  is 
database  centric.  For  example,  if  we  wanted  to  add  another  machine  type,  then  we  would  just  add 
another  row  in  the  database.  We  want  to  capture  all  the  information  from  top  to  bottom  as 
relations  with  the  use  of  templates,  so  that  if  we  make  changes,  then  we  just  have  to  change  the 
templates.  I anticipate  that  we  are  eventually  going  to  have  a table  of  functions,  analysis 
functions,  so  that  we  can  add  to  those  functions.  Another  aspect  to  this  is  that  we  want  the 
repository  to  be  distributed,  which  means  that  we  might  have  a pointer  to  say  the  Boeing  database 
and  may  have  a password.  The  analysis  would  then  have  the  capability  of  querying  the  Boeing 
databases  (at  least  those  in  which  we  have  been  granted  permissions)  where  the  linkage  is 
performed  with  ODBC.  We  need  to  talk  about  the  management  and  security  issues  of  this  type  of 
database.  This  might  point  to  a data  dictionary  at  another  site.  This  would  mean  that  NIST 
doesn’t  have  to  be  the  central  location  for  the  repository.  Other  companies  may  use  all  or  part  of 
this  design  for  their  systems.  Another  thing  that  is  very  important  is  extensibility.  I want  to  push 
the  relational  model  to  see  how  much  extensibility  we  can  practically  obtain.  I heard  somebody 
say  that  there  might  be  performance  issues  with  ODBC.  Remote  Database  Access  (RDA)  might 
be  a faster  method  of  accessing  databases,  but  I haven’t  tested  this  method. 

Functionality  and  Design.  [Slide  10-8].  The  critical  issue  is  to  design  the  database  for 
extensibility.  We  need  to  work  on  management  of  the  distribution.  One  of  the  problems  with  a 
distributed  system  is  the  firewall.  Vivek  talked  about  cooperation  and  demonstrations.  The 
firewall  technology  blocked  us  from  setting  up  communication  (audio  and  video)  from  NIST  to  a 
Caterpillar  shop  floor. 

KATTER:  In  terms  of  functionality,  are  you  going  to  link  to  the  machine  tool  classification 
work? 
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WELSCH:  We  probably  should. 


COVINGTON:  I was  thinking  about  the  functionality  and  priorities  of  your  layout.  We  need  to 
get  visibility  on  these  before  they  happen. 

WELSCH:  Right  now,  achieving  the  distributed  aspect  of  the  repository  is  important  to  me. 

COVINGTON:  I am  concerned  about  the  functionality  and  what  the  repository  is  going  to  do. 

DONMEZ:  Those  are  essential  questions  for  the  road  map.  We  don’t  have  too  much  time  to 
discuss  today.  However,  we  can  discuss  the  road  map  the  first  thing  tomorrow  morning.  I would 
like  everybody  to  think  about  what  type  of  functionality,  how  to  fill  in  the  gaps,  and  what 
priorities  are  needed  for  the  repository. 


53 


Integrated  Design  and  Build  Processes  at  Raytheon/Texas  Instruments 

Richard  Johnson 
Raytheon/Texas  Instruments 


We  have  been  doing  work  for  the  last  9-10  years  on  our  design  process.  We’ve  undertaken  a 6a 
initiative  where  we’ve  tried  to  implement  the  concepts  of  6a  into  our  design  process  instead  of 
only  the  manufacturing  arena  and  use  those  techniques  to  predict  what  defects  we  will  have  and 
then  design  the  defects  out  before  we  get  into  the  production  domain.  That  has  required  us  to 
bring  a lot  more  information  that  normally  resides  downstream  upstream.  Some  of  that 
information  is  the  data  that  we  have  been  talking  about  in  these  workshops.  One  of  the  problems 
that  we  had  when  we  started  doing  this,  is  that  the  data,  which  was  in  the  format  used  in 
manufacturing  to  control  the  shop,  really  didn’t  do  the  design  engineers  any  good  until  it  was 
translated  into  what  should  be  specified  in  a drawing  (i.e.,  dimensions,  tolerances,  materials, 
features,  etc.). 

When  we  looked  at  the  design  process,  looked  at  the  product  lifecycle  (probably  at  the  highest 
level),  you  design  something,  you  build  it  and  you  can  see.  [Slide  11-1].  You  break  that  design 
and  build  down.  When  we  go  through  a conceptual  design  or  we’re  handed  a set  of  system  level 
specifications  and  have  to  back  translate  that  to  a set  of  requirements  and  specifications  that  flow 
down  into  lower  levels  of  product  structure.  Then  we  go  into  detailed  design.  Then  we  usually 
prototype.  Then  we  go  into  build.  This  prototyping  phase  is  what  we  are  talking  about  at  this 
consortium  and  what  we’re  trying  to  do  in  a virtual  manner  instead  of  actually  building  hardware, 
which  would  be  a big  improvement  over  what  we’re  doing  now.  If  you  look  down  here  at  the 
bottom  end  of  the  process,  where  you  have  the  build  process,  we  use  machines  to  build.  [Slide  1 1- 
2].  We  collect  data  from  the  machines,  get  the  trends  and  other  types  of  information  on  what’s 
happening  with  those  machines,  and  we  use  that  information  to  control  the  machines.  That’s,  at  a 
very  high  level,  of  what  we’ve  been  doing  with  the  data  in  the  past. 

What  we’re  trying  to  do  in  this  consortium,  is  take  that  same  data  and  probably  some  other 
information  that  we  don’t  currently  use,  build  models  for  these  tools  and  try  to  simulate  what  is 
going  on  in  the  process.  [Slide  11-3].  Input  our  feature  geometry  for  virtual  prototyping  and 
output  what  our  capability  is  of  those  production  processes.  Actually  verify  that  we  can  produce 
this  part.  I should  have  included  a feedback  loop  to  the  design  in  case  the  design  doesn’t  work, 
and  build  several  prototypes. 

What  we’ve  been  doing  in  the  last  4 years  is  that  we’ve  skipped  the  virtual  prototyping  step  and 
haven’t  been  building  any  models  for  our  tools.  [Slide  11-4].  We  have  been  building  process 
models  where  we’ve  taken  information  that  we  normally  use  in  the  shop  and  have  translated  that 
into  models  that  will  give  us  the  predicted  output  of  the  process  in  terms  of  the  cost  cycle,  given 
the  part  geometry,  that  is  a set  of  features,  not  just  one  individual  feature.  That  will,  basically, 
give  us  information  about  our  yields.  We’re  trying  to  move  upstream  and  improve  the  designers’ 
capability  to  design  the  something  right  the  first  time  so  when  we  go  into  the  prototype  phase,  we 
don’t  go  through  several  iterations  back  into  the  design  and  then  prototyping. 

Ultimately,  we  are  doing  some  work  here  too,  we  have  what  we  call  process  technology  levels 
and  modeling  different  process  technologies  of  metal  fabrication,  which  could  be  casting,  sheet 
metal,  composites,  hog  outs,  which  do  you  use  and  we  make  those  kinds  of  decisions  up  in  the 
conceptual  phase  of  design  before  we  move  to  the  detailed  design.  [Slide  1 1-5].  We  need  models 
up  there  to  help  us  decide  what  are  the  right  technologies  to  use  in  our  detailed  design  to  help 
point  us  in  the  right  direction.  Instead  of  getting  all  the  way  down  here  in  prototyping  and  find 
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out  that  we  should  have  made  this  in  casting  instead  of  a hog  out  or  vice  versa.  Up  there  we  have 
system  level  specifications  that  we  feed  into  the  models,  which  gives  us  back  which  technology  is 
the  best  fit  for  your  requirements  for  this  system. 

One  thing  that  we  have  found  out  now  that  we’re  starting  to  develop  those  models,  is  that  expert 
knowledge  plays  a large  role  in  this,  because  all  of  the  data  that  we  can  collect  doesn’t  tell  us 
everything.  [Slide  11-6].  There  is  a lot  of  information  that’s  impossible  or  very  difficult  to  put 
into  numbers.  We  have  expert  knowledge  that  we  have  to  add  to  the  modeling  process.  This  is 
our  vision  where  we  would  like  to  see  the  modeling  go,  and  bringing  production  data  into  the 
design  process. 

I think  there  are  probably  four  levels  of  modeling  that  need  to  be  done,  one  was  added  due  to 
what  we’re  doing  in  this  consortium.  [Slide  1 1-7].  What  we’re  trying  to  do  with  the  technology 
models  is  really  to  vector  the  design  team  in  the  right  direction.  Build  those  models  at  a level  of 
abstraction  that  will  allow  you  to  understand  which  technologies  you  should  use  given  your 
system  level  requirements.  For  the  process  models,  we’re  using  those  to  try  and  optimize,  once 
we  determine  which  direction  we’re  going  to  go,  what  kind  of  technologies  we’re  going  to  use, 
then  we  use  the  process  models  to  optimize  what  we’ve  made  a decision  to  do.  Then,  as  we  start 
implementing  virtual  prototyping  capability,  then  the  prototyping  will  initially  be  a part  of  the 
design  process,  that  is,  we  will  go  to  virtual  prototyping  to  help  us  make  design  decisions  as  we 
improve  our  process  and  technology  level  model.  Eventually,  we  see  that  is  ideally  just  a 
verification,  and  that  we  can  confidently  state  that  “this  design  is  ready  to  go  into  production”. 
Then,  of  course,  you  go  into  the  build  cycle,  and  this  is  what  has  been  out  there  for  years:  the 
capability  to  collect  data  and  use  that  to  control  your  production  cycle. 

HEMMERLE:  In  your  stage  1,  where  you  show  build  in  machine  and  data,  is  that  product  data  or 
machine  data  that  you  are  looking  at? 

JOHNSON:  Machine  data  in  the  context  of  controlling  at  the  shop  level. 

HEMMERLE:  By  machine  data,  the  geometry  of  the  machine  and  the  squarenesses  of  the 
machine  or  the  resulting?  6a  to  me  goes  pretty  strong  on  product,  as  opposed  to  the  machine 
level.  Were  you  looking  at  the  hardware  produced  from  the  machine  or  were  you  actually 
looking  at  the  machine  for  that  data? 

JOHNSON:  In  the  past,  it  has  primarily  been  looking  at  what  has  happened  to  the  product  and 
what  are  the  trends  in  generating  these  types  of  features.  We’re  talking  about  building  prototypes 
now,  which  will  probably  bring  into  that  database  additional  information  like  what  you’re  talking 
about  for  the  machine  itself,  trying  to  model  the  machine.  The  database  is  somewhat  notional  and 
all-inclusive  and  as  you  move  up  the  stream,  the  database  gets  larger  with  the  types  of 
information  included.  Some  of  that  information  for  tool  models  will  probably  be  used  eventually 
for  us  to  improve  our  process  models.  Then  our  process  models  will  be  used  to  give  us  the  ability 
to  build  good  process  technology  level  models.  We  have  some  activity  going  on  in  the  top  levels 
of  the  diagram.  The  last  up  in  level  IV.  This  is  our  vision  of  where  to  go  with  the  modeling  and 
what  role  the  data  plays  in  the  lower  levels.  It  is  somewhat  undefined  at  this  point  specifically 
what  information  is  needed  to  do  the  entire  diagram,  but  for  the  prototype  models,  that  is  what 
we’re  talking  about  in  this  consortium;  what  information  do  we  need,  what  format  would  we  put 
it  in,  how  would  we  use  it,  how  do  we  actually  go  do  virtual  prototyping?  That  is  going  to  help 
us,  once  we  start  getting  information,  from  that  level,  to  improve  our  ability  to  model  those  higher 
levels.  I want  to  get  some  feedback  to  see  if  this  seems  reasonable  to  you.  I know  that  the 
objectives  of  this  consortium  are  limited  to  primarily  level  II. 
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DONMEZ:  We  are  concentrating  on  Levels  I and  II  at  this  time,  which  is  my  impression  based 
on  all  of  the  discussions  that  we  are  having.  Don’t  you  need  machine  tool  models  in  process 
models  in  the  prototyping  stage? 

JOHNSON:  I look  at  the  model  as  part  of  the  data,  as  a type  of  data.  I look  at  these  different 
levels  of  modeling  using  different  levels  of  abstraction  of  data.  We  have  to  use  data  at  more 
abstract  levels  to  model  those  technologies  at  the  higher  levels. 

DONMEZ:  So  when  you  talk  about  process  models,  you  are  not  talking  about  modeling  the 
cutting  process? 

JOHNSON:  I’m  talking  about  modeling  the  turning  process  that  we  use  (OD,  ID,  roundness, 
lengths,  diameters,  etc.).  If  I have  a part  that  is  a turned  part,  instead  of  just  saying  that  I have  a 
diameter  here,  have  a roundness  at  the  nominal  at  this  feature,  etc..  I have  a part  that  I have 
described  every  dimension,  put  all  of  that  together  and  use  your  data  and  process  model  and  tell 
me  what  is  the  expected  defect  rate  for  this  process.  It  doesn’t  look  at  each  one  of  the  surfaces  we 
have  available,  but  it  looks  at  the  feed,  speed,  and  what  is  going  to  show  up  when  I inspect  this 
part,  the  type  of  information  we  are  looking  at  is  at  a lower  level  of  detail.  We’re  are  looking  at  a 
lower  level  of  abstraction. 

DONMEZ:  Are  you  talking  about  Cpk  type  of  information  for  your  process  models? 

JOHNSON:  Yes.  We’re  looking  at  Cpk,  6a. 

WELSCH:  When  you  bring  in  the  expert  knowledge,  what  are  your  thoughts  on  representing 
how  that  information  will  be  used  from  a software/systems  standpoint? 

JOHNSON:  I’m  not  sure  since  I’m  not  a software  person,  so  I’m  not  sure  I understand  the 
question.  There  are  different  levels  of  abstraction  that  we  have  to  look  at  to  determine  the  overall 
system.  When  we  put  our  process  models  together,  we  found  out  that  roughly  half  of  the 
information  we  needed  to  model  processes  was  not  available.  So  we  had  to  go  to  the  process 
experts,  ask  questions,  and  have  them  reach  a consensus  to  what  the  most  acceptable  answer  to  a 
particular  question,  then  put  the  result  into  the  database.  The  reason  we  allow  that,  as  opposed  to 
purely  numerical  data,  since  there  is  no  existing  data  for  those  questions,  we  would  have  to  go 
through  that  process  anyway.  However,  since  you  don’t  get  the  same  answer  from  all  of  the 
experts,  the  answers  may  be  within  some  range  of  the  spectrum,  you  need  to  come  up  with  a 
consistent/acceptable  answer  to  the  question  as  part  of  the  model.  We  have  software  guys  that  are 
working  and  integrating  that  information  into  our  models.  I’m  not  sure  how  it  is  included  in  the 
database.  We  do  have  information  that  is  non-numerical.  We  have  restrictions  and 
interrelationships  that  we  get  from  our  process  engineer.  We  have  rules  where  we  know  if  we  do 
“x”  and  “y”  then  you  better  not  do  “z”.  Alternatively,  if  you  if  you  do  “w”  then  the  result  is  “3v”. 

WELSCH:  How  that  expert  knowledge  is  integrated  into  the  database  would  be  a significant 
contribution  to  this  consortium. 

JOHNSON:  I can  check  with  our  software  development  people.  Maybe  we  can  work  something 
out. 

COVINGTON:  We’re  dealing  with  some  of  the  same  issues  and  trying  to  get  data  from  process 
experts  from  the  shop  floor. 
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MCCLURE:  Alkan  Donmez,  Dave  Hemmerle,  and  I are  involved  with  writing  a book,  and  this 
fits  in  perfectly  and  it’s  something  I’d  like  to  talk  to  you  and  maybe  the  four  of  us  could  get 
together  later.  At  the  very  least,  I would  like  copies  of  the  viewgraphs. 

JOHNSON:  I’d  like  some  feedback  on  this.  I had  left  that  level  out  before. 

DONMEZ:  We’re  concentrating  on  Levels  I and  II  in  your  diagram,  but  we  can’t  ignore  the 
higher  levels.  That’s  why  in  my  agenda  I wanted  to  capture  the  role  of  this  repository  in  the  big 
picture  of  virtual  manufacturing  information  systems. 

JOHNSON:  These  aspects  of  Levels  I and  II  are  the  foundation  for  being  able  to  do  any  of  these 
Levels  on  the  diagram.  My  interest  is  when  the  standard  is  set  for  machine  tool  capabilities. 
Keeping  in  mind  that  the  same  database  and  architecture  may  be  used  for  modeling  upstream. 

COVINGTON:  The  things  you’re  talking  about  are  my  key  objectives  and  that’s  what  I want  to 
produce.  We’re  doing  these  things  in  a machine  measurement  arena  in  order  to  satisfy  some  of 
the  requirements. 

JOHNSON:  I think  this  fits  into  the  concept  of  the  layered  database,  that  is,  different  levels  of 
abstraction. 

COVINGTON:  Do  you  have  anything  that  you  could  give  us  which  is  more  detailed? 

JOHNSON:  We’re  running  into  legal  problems,  being  an  engineer  that’s  the  part  I hate,  but  I can 
talk  to  you  later. 

MCCLURE:  I’ll  just  call  your  attention  to  something  else  that  just  came  out  of  your  shop  a 
couple  of  years  ago.  John  Schaeffer  at  one  of  the  American  Society  for  Precision  Engineering 
(ASPE)  Spring  meetings  presented  a case  study  that  came  out  of  Texas  Instruments  (TI),  which 
was  the  most  concrete  examples  of  concurrent  engineering  that  I’ve  ever  seen.  He  did  a beautiful 
job,  it’s  in  parallel  to  this.  He  did  an  actual  optical  system,  and  his  case  study  took  it  from  the 
conceptual  design  to  the  manufacturing  and  how  all  of  the  interconnecting  loops  (people 
connections  instead  in  data  connections)  but  it’s  analogous  to  what  you  presented. 

JOHNSON:  These  are  tools  that  those  people  use. 

MCCLURE:  Right.  Nevertheless,  it  was  a beautiful  description  of  concurrent.  It  was  the  first 
time  that  I understood  that  concurrent  meant  concurrence  between  people,  not  simultaneous.  Is 
that  the  way  TI  sees  that? 

JOHNSON:  That’s  the  way  everybody  interprets  concurrence  the  other  way.  Nevertheless,  I 
agree  with  what  you’re  saying. 

DONMEZ:  I received  a short  white  paper  from  Richard  Jennings  of  MIMITEK,  who  was  in  the 
first  workshop.  You  saw  some  of  the  software  pieces  that  they  developed  in  Dan  Sawyer’s 
presentation  yesterday.  They  are  looking  at  uncertainties  in  CMMs  but  are  also  interested  in 
applications  to  machine  tools  as  well.  The  white  paper  is  included  in  Appendix  III. 
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I had  another  discussion  with  Don  Esterling  this  morning.  About  the  simulation  tools  and  how 
useful  they  are,  what  are  the  potential  uses  in  your  operations.  Don  has  some  ideas  that  he  would 
like  to  share  with  us  to  make  some  points  more  clear. 

ESTERLING:  Alkan  Donmez  asked  us  to  think  last  night,  which  could  be  dangerous.  I had 
some  conversations  with  Jim  Covington  (Boeing)  and  Chris  DeForge  (Deneb),  who  brought  up 
the  issue  of  “how  are  you  going  to  use  these  simulation  packages”.  As  I understand  it,  you  have  a 
significant  amount  of  data  that  is  being  developed  and  then  filtered  down  to  some  point  where 
you’re  generating  some  kind  of  part.  The  point  that  I made  yesterday  was  that  men  are  not 
angels.  The  metrology  engineers  may  understand  the  data  that  characterizes  the  machine  tool  and 
may  know  what  to  do  with  the  data  in  terms  of  predicting  the  part  on  the  machine  tool.  However, 
you  have  a guy  on  the  shop  floor  who  may  not  be  having  a good  day,  chooses  to  ignore  the  data, 
or  just  doesn’t  understand  the  data.  You  need  to  develop  some  kind  of  tool  where  the  guy  on  the 
shop  floor  can  easily  make  sense  of  the  data  and  gives  a simple  answer  to  whether  or  not  the 
system  will  work.  We  need  a system  that’s  easy  to  use,  convenient,  automated,  and  reliable. 
That’s  the  point  that  we’re  trying  to  make  with  the  error  modeling  system.  With  an  error 
modeling  simulation  system,  whether  it  is  API,  Deneb,  or  N-See,  you  have  a possibility  of 
experimenting.  I’m  not  sure  Dave  Hemmerle  wants  his  guys  experimenting  on  the  shop  floor 
with  production  parts.  If  they  have  a system  inside  their  computer,  they  can  experiment  and  try 
putting  the  part  at  different  places  of  the  workspace.  Given  the  part  characteristics  and  the  part 
program,  I can  “machine”  the  part  at  different  places  and  get  a sense  of  where  best  to  machine. 
The  shop  floor  guys  will  learn  from  the  simulations  and  get  a better  gut  feeling  about  how  to  use 
the  raw  data  that  is  coming  from  machine  characterization  tests.  The  second  point  that  I wanted 
to  make  is  that  men  are  not  perfect.  Mistakes  may  be  made  from  the  part  program,  another  may 
come  from  the  CAM  system  itself,  where  modeling  at  the  tool  tip  you  have  an  insert  where  the 
back  edge  of  the  insert  may  brush  against  a curved  surface  and  the  poor  part  programmer  doesn’t 
have  any  way  to  model  that.  Even  on  perfect  machine  systems,  you  need  a simulation  tool  that 
will  check  the  part  tolerances  given  the  part  program.  However,  maybe  a perfect  system  doesn’t 
gouge  the  part,  but  the  part  program  coupled  with  the  error  model  predicts  that  the  tolerances  will 
not  be  met.  In  theory,  rough-cuts  never  invade  the  tolerance  level.  In  practice,  there  are  all  kinds 
of  war  stories  that  prove  otherwise  where  gouges  take  place  where  you  don’t  even  expect 
tolerances  to  be  violated. 

DONMEZ:  The  other  point  is,  that  we  are  talking  about  a significant  amount  of  data,  in  order  to 
make  some  sense  of  the  data  we  need  some  visualization  tools. 

MCCLURE:  There  are  many  things  in  error  modeling  that  can  be  added  for  simulation 
procedures.  I will  agree  with  you  that  there  is  more  than  the  finish.  Results  of  all  of  this,  is  a 
better  understanding  of  processes,  how  to  control  them,  and  how  to  predict  what  the  final  part  will 
be.  The  result  of  controlling  and  managing  this  whole  process  is  that  there  will  be  new 
generations  of  machines.  Continuing  the  evolution  that  has  started  with  N-See  Software,  will 
yield  multifunctional  machines  which  will  bore,  drill,  turn,  etc..  Particularly  if  the  results  of  a 
group  such  as  this  bear  fruit.  The  things  that  are  not  going  to  be  covered,  such  as  the  subtleties 
of:  fixturing  problems,  the  effect  of  one  operation  on  a part  where  the  material  is,  or  how  the  part 
will  spring  back  when  fixturing  is  removed.  Those  issues  are  several  layers  down.  I agree  that 
we  can’t  afford  to  oversimplify. 

HEMMERLE:  By  the  time  you  get  all  of  the  error  modeling  done  at  the  great  manipulator  in  the 
sky,  do  you  not  think  I will  have  volumetric  compensations  at  the  control  level? 
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ESTERLING:  Controls  will  get  smarter.  There  will  be  some  compensation  that  comes  out  of 
this  effort. 

DONMEZ:  You  are  right.  If  you  have  models,  and  those  models  are  correct  for  your  machine, 
then  you  can  compensate  for  the  errors.  However,  how  stable  the  models  are,  is  critical.  You 
may  introduce  apparent  nonsystematic  errors  into  the  system  with  your  model.  For  example,  if  I 
have  a model  that  gives  me  purely  geometric  compensation  of  the  machine,  what  will  happen 
towards  the  end  of  the  day?  But  with  modeling,  we  can  put  bounds  into  the  characteristics  of  the 
machine,  as  we  saw  in  Dan  Sawyer’s  presentation  of  apparent  uncertainties  in  models,  and  you 
can  then  predict  changes  that  are  occurring  in  your  machine  and  how  that  effects  the  part.  That 
doesn’t  mean  that  your  prediction  will  exactly  match  your  part,  but  you  will  have  range  of 
dimensions/errors  of  your  part  that  you  can  estimate  for  a given  time  and  condition  of  the 
machine.  Since  you  are  not  tracking  every  detail  of  the  machine  that  effects  accuracy  of  the  part, 
then  you  will  not  be  able  to  make  all  of  the  corrections  on  the  machine.  You  can  make  some 
baseline  corrections,  such  as  lead  screw  (which  everybody  already  does).  In  the  next  few  years, 
most  of  the  new  machines  will  probably  have  basic  geometrical  correction  capability.  However, 
you  still  end  up  with  errors  on  the  machine,  which  will  be  changing  slowly. 

HEMMERLE:  Just  before  I produce  high  accuracy  into  the  workpiece,  I check  certain 
characteristics.  Immediately  upon  finishing  those  characteristics,  I check  it  again.  In  addition,  I 
see  that  the  self-induced  and  process- induced  thermal  (I’m  calling  it  thermal)  distortions  that 
occur.  Now,  when  that  becomes  fairly  consistent,  I statistically  infer  the  compensation  needed. 

If  I know  that  I’ll  tend  to  always  grow  slightly  left,  and  by  how  much  and  I have  a good 
correlation/control  on  that.  When  I go  through  and  pick  up  my  initial  offsets,  I will  throw  it  a 
little  to  the  right  so  it  will  grow  in  before  it  grows  out.  Therefore,  I do  some  live-time  adjustment 
for  the  reality,  not  real-time. 

DONMEZ:  In  order  for  you  to  do  that,  you  have  collected  a significant  amount  of  data,  and  this 
is  probably  for  one  machine.  The  amount  of  data  builds  up  significantly. 

HEMMERLE:  There  is  a significant  amount  of  data  and  it  is  very  machine  sensitive. 

DONMEZ:  You  are  going  to  have  to  make  sense  out  of  that  data,  and  that’s  where  the 
visualization/simulation  tools  appear.  It  makes  the  analysis  easier  when  you  can  visualize  what 
effect  the  current  environmental  conditions  and  behaviors  of  the  machine  will  have  on  the 
resulting  part.  If  I can  look  at  the  (virtual)  part  as  a function  of  time,  instead  of  making  parts,  and 
shrinking  all  of  the  knowledge  of  the  process  into  the  computer  domain,  then  I can  see  the  trends 
and  I can  convert  those  trends  into  actions.  It  is  very  useful  to  see  these  things  happening  on  the 
computer  screen  first  rather  than  on  the  shop  floor. 

ESTERLING:  I think  you’re  right  Dave,  but  again  the  issue  of  how  much  do  you  compensate. 
Wouldn’t  it  be  nice  to  have  a tool  where  you  can  try  out  different  compensation  strategies. 

DEFORGE:  I keep  coming  back  to  the  question  of  what  are  my  customers  going  to  be  using 
these  simulations  for?  How  does  our  company  fit?  Right  now,  our  customers  are  saying  “we 
have  problems  with  capacity,  and  the  only  way  to  increase  the  capacity  quickly  is  to  take  the 
production  process  offline  and  move  into  the  virtual  environment  and  keep  our  machines 
running”.  That’s  one  area  where  our  customers  have  asked  us  for  help.  Another  area  in  which 
they  have  requested  assistance  is  understanding  more  about  the  overall  process  (part  or  tooling) 
early  on  in  the  design  phase  of  that  process  and  our  customers  need  the  tools  to  help  in  these 
areas.  Those  are  essential  areas.  There  are  so  many  subtle  pieces  of  information  that  varies  from 
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machine  to  machine.  I look  at  all  of  this  data  and  can’t  see  an  interface  that  would  be  clean  and 
easy  to  use.  I have  to  focus  on  areas  that,  I think,  the  customers  are  asking  for  now.  For  instance, 
if  I were  able  to  take  an  entire  work  envelope,  and  say,  make  a cloud  pixels  or  color  shade,  that 
would  give  me  a 3-D  perspective  of  where  the  inaccuracies  of  a particular  machine  are.  I think 
the  design  phase  would  include  fixtures  and  processes  that  we  develop,  since  I would  have  to 
“fit”  my  part  into  the  most  accurate  zones  of  this  particular  machine.  What  kind  of  data  do  I need 
to  do  that?  I need  you  all  to  help  me  understand  that.  As  opposed  to  just  grabbing  all  of  the 
information  and  making  sense  out  of  it,  I think  we  need  to  focus  on,  from  the  simulation  side  of 
this  project,  who  the  customers  are  and  what  they  are  going  to  be  asking  simulations  to  do,  and 
what  is  going  to  remain  part  of  the  company’s  knowledge  base  or  experts,  such  as  you,  who  know 
the  machine  tool  very  well  and  have  to  make  human  judgments  of  how  the  machine  can  perform 
instead  of  using  the  software  making  decisions. 

HEMMERLE:  Also,  we  are  rapidly  going  away  from  process  centers  to  product  centers.  Part 
ABC  is  only  going  to  be  ran  on  this  machine,  that  style,  that  style,  that  style.  We  will  no  longer 
have  a bank  of  machine  tools  and  the  part  may  go  to  any  one  of  them.  They  are  all  being  split  up 
into  product  cells.  That’s  going  to  cause  real  difficulties. 

ESTERLING:  I think  that  is  what  Caterpillar  is  doing.  They  are  compiling  errors,  say  for 
straightness,  and  only  worrying  about  what  you’re  doing  with  the  part  to  see  which  errors  are 
most  crucial  for  what  features. 

COVINGTON:  I do  things  a little  bit  differently  than  they  do.  We  still  have  many  different 
types  of  parts  associated  with  each  machine.  We  have  many  parts,  close  to  20000  parts.  I don’t 
have  time  to  force  all  of  these  parts  into  a particular  area  of  the  machine.  I want  to  know,  by 
pressing  a button,  if  this  part  is  going  to  be  machined  within  tolerance  or  not.  I don’t  have  time  to 
go  looking  at  the  pixel  information  of  a simulation  system.  I want  to  know  if  my  machine  can 
handle  the  job.  I want  a yes/no  type  of  framework.  I’m  looking  for  more  than  a smarter  system 
that  tells  me  whether  or  not  I can  make  the  part  on  existing  machines  or  if  I have  to  outsource.  I 
need  a quick  answer  to  the  problem;  not  on  a part  by  part  basis.  I need  analysis  on  a part  family 
basis  based  on  tolerances  of  the  part  and  geometry.  Capacity  is  a big  issue.  I can’t  have  my  NC 
program  center  looking  at  pixels  trying  to  figure  out  how  to  fix  the  machine  or  where  on  the 
machine  to  put  that  part.  While  they’re  doing  that,  the  schedule  is  slipping. 

DONMEZ:  Maybe  the  maintenance  people  on  the  shop  floor  would  be  looking  at  the  problem 
from  a different  angle. 

COVINGTON:  They’re  not  looking  at  it  from  a part  specific  angle. 

DONMEZ:  However,  they  still  need  to  look  at  the  data  to  gain  some  understanding  of  the 
process. 

SOONS:  On  the  compensation  issue,  it  makes  a difference  whether  you  are  making  different 
types  of  parts  with  the  same  machine,  or  using  one  machine  to  make  only  one  type  of  part.  If  you 
use  the  same  machine  to  make  the  same  part  over  and  over,  then  there  are  more  effective 
alternatives  than  what  we  are  discussing  here  for  compensation. 

DONMEZ:  I think  the  general  trend  is  that  you  are  changing  product  lines  more  quickly,  so  you 
don’t  have  the  situation  where  you  are  making  only  one  part  on  one  machine  repeatedly. 
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KATTER:  I think  many  times,  to  answer  the  yes/no  questions,  you  have  more  issues  than  just  the 
machine  tool  errors.  You  have  fixturing  problems,  environmental  issues,  etc..  It’s  not  as  simple 
as  a yes  or  no  question. 

KRULEWICH:  I was  wondering  how  much  of  this  is  machine  specific  and  how  much  is  machine 
family  specific?  It  seems  like  if  you’re  designing  a part  and  if  you  want  to  know  if  you  can  make 
that  part  on  a specific  machine,  then  you  probably  want  to  know  more  generally  on  a particular 
type  of  machine  for  the  lifetime  of  the  machine;  not  looking  at  the  machine  for  this  one  particular 
instance  in  time  when  the  errors  are  acting  a certain  way.  I can’t  imagine  in  a high  volume 
production  that  you  would  have  a machinist  optimizing  a part  for  the  way  the  machine  is  acting 
today.  The  question  is,  are  you  looking  for  a family  of  machines  that  can  be  classified  to  having 
certain  types  of  errors?  We  don’t  have  high  volume  production,  but  I can’t  imagine  our  machinist 
trying  to  optimize  the  part  placement  on  a particular  machine.  In  high  volume  production,  I can 
see  where  it  would  be  prohibitive.  Then  we  were  talking  about  errors  that  you  can  compensate 
for  machines. 

DEFORGE:  That’s  what  I was  asking  you  yesterday.  Can  you  characterize  some  of  these  errors 
that  can  be  associated  with  a particular  model  of  machine  tool? 

KRULEWICH:  I think  it  would  have  to  be  more  in  a statistical  sense,  such  as  a Monte  Carlo 
simulation  looking  at  parts  with  certain  features,  looking  at  errors  with  some  tolerance  range. 

COVINGTON:  You  have  a lot  of  variation  in  health  quality  of  machines  of  the  same  model  as 
they  age. 

KRULEWICH:  Given  that  you  have  two  machines  of  the  same  model,  you  might  have  a certain 
part  that  you  could  make  on  one  but  not  the  other.  It’s  on  a custom  basis. 

COVINGTON:  In  the  best  of  all  worlds,  all  machines  of  the  same  model  should  perform  the 
same.  In  our  maintenance  capability,  we  have  to  look  at  each  machine  individually.  Each 
machine  has  its  own  specific  problems. 

HEMMERLE:  Debbie,  when  I get  48  pallets  from  four  load  stations  from  16  machines.  You  tell 
me  any  operation  and  I can  tell  you  the  best,  second,  third,  fourth.  That’s  going  to  be  response 
time.  So  it  is  automatically  calculated. 

DEFORGE:  I have  a pretty  fundamental  question  from  some  of  the  data  that  we  saw  yesterday. 
We  were  talking  about  data  along  the  XY  plane.  Can  that  data  be  extrapolated  out  into  the  3- 
dimensional  sense  or  do  you  have  to  go  in  and  identify  its  own  characteristics?  How  do  we  go 
from  2-dimensional  to 
3-dimensional? 

HEMMERLE:  Yes.  We  have  a plot  of  where  all  of  the  high  accuracies  are  produced.  Low 
accuracy  is  like  runway  behind  you  and  altitude  above  you,  it  doesn’t  count.  Where  high 
accuracy  is  produced,  that  is  your  mean  tool  point  intersections.  That  is  where  I want  my 
compensations  to  be  effective.  Now,  can  I take  them  lower  and  project  them  there?  Yes.  I have 
my  pitch,  rolls  and  yaws  and  I believe  that  I can  mathematically  project. 

DEFORGE:  Are  we  clever  enough  to  do  the  projections? 
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HEMMERLE:  From  Hans  Soons’  presentation  of  the  data  dictionary,  the  placement  of  the 
metrology  sensors  is  critical  to  the  projection  calculations.  From  Hans’  data  format,  I can  project 
the  accuracies  to  any  lines  I want. 

SOONS:  Your  question  is  very  valid.  There  are  certain  theories  about  what  kind  of  errors  you 
need  in  order  to  project.  One  of  those  theories  that  is  most  often  used  is  that  each  axis  has  6 
errors  associated  with  it,  3 displacements  and  3 rotations,  and  you  use  simple  mathematics  to 
translate  the  errors  into  the  machine  workspace  for  every  machine  axis.  So  if  you  have  a 3-axis 
machine  you  end  up  with  1 8 errors  plus  3 errors  added  for  squareness.  By  that  limited  set  of 
errors,  it  is  hoped  that  you  will  be  able  to  predict  every  error  in  the  workspace. 

DEFORGE:  The  various  tests  that  you  were  describing  in  your  presentation  yesterday.  Does 
each  one  of  those  tests  provide  the  same  information  ultimately  and  just  different  methods  for 
gathering  them? 

SOONS:  They  were  different  methods  of  gathering  various  classes  of  errors.  In  addition,  when 
you  use  this  type  of  error  model  you  have  to  be  very  careful.  For  example,  the  error  that  you 
measured  depends  very  much  on  where  in  the  workspace  the  measuring  took  place.  Basically, 
the  position  of  your  machine  axes.  The  projections  that  we  are  specifying  here,  you  definitely 
need  to  know  where  you  are  measuring  that  error.  That  is  one  of  the  reasons  we  are  so  insistent 
of  having  the  level  of  detail  of  how  the  data  was  taken  integrated  into  the  database.  Back  to  your 
original  question,  the  message  is  that  there  is  a limited  number  of  errors.  You  can  do  a 3- 
dimensional  prediction  of  your  errors. 

DONMEZ:  I think  what  we  should  keep  in  mind,  is  that  some  visualization/simulation 
capabilities  would  be  beneficial.  How  much  and  in  what  circumstances  still  need  to  be 
determined  and  we  shouldn’t  place  any  boundaries  at  this  time.  What  we  should  keep  in  mind,  if 
we  need  such  visualization/simulation  tools,  what  do  we  have  to  provide  to  those  tools  as 
information/data  and  how  can  we  standardize  that  such  that  N-See,  Deneb,  and  other  companies 
can  develop  tools  based  on  users’  requirements/needs.  That’s  where  I think  our  focus  should  be, 
not  on  the  specific  application  of  the  simulation,  but  what  kinds  of  things  that  we  need  in  the 
future  and  how  to  provide  standardized  interfaces  for  the  tools.  Eventually  different  types  of 
tools  will  emerge. 

DEFORGE:  Would  it  make  sense,  for  the  quick  decisions  that  Boeing  is  asking  for,  that  if  you 
just  have  a 3-D  error  map  for  machine  tools  based  on  data  collected  for  a specific  machine.  Just 
take  a finished  part,  manipulated  through  that  3-D  map,  to  see  if  this  machine  would  produce  the 
part  within  tolerances.  If  not,  then  go  to  the  next  machine  and  perform  the  same  evaluation  based 
on  the  last  set  of  data  for  that  particular  machine.  Would  that  be  a comfortable  evaluation?  That 
would  be  a fundamental  check,  does  the  machine  have  the  capability  to  produce  the  part  within 
tolerances  or  not.  Once  that  decision  is  made,  then  you  can  include  more  information  into  a 
model  and  address  more  of  the  process  evaluation  issues,  such  as  fixturing,  optimization  of 
placement  of  part,  etc..  Just  take  the  data  and  evaluate  it  visually.  Do  you  think  that  is  valuable? 
If  I can  get  a consensus,  then  I can  start  moving  in  that  direction. 

COVINGTON:  I don’t  think  the  visualization  is  necessary,  just  a yes  or  no  on  whether  or  not  the 
tolerances  have  been  violated  within  a certain  workspace.  I don’t  want  to  make  any  decisions, 
just  a yes  or  no. 

HEMMERLE:  If  it  doesn’t  pass  on  one  machine,  you  have  to  go  to  another  machine. 
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COVINGTON:  You  may  want  to  do  that,  and  have  that  capability. 

DEFORGE:  I take  it  the  next  step  is  then,  that  there  are  going  to  have  to  be  other  decisions  about 
fixture  design,  etc.. 

COVINGTON:  I don’t  want  to  go  in  and  change  the  NC  program. 

WELSCH:  You  are  saying  that  you  don’t  need  the  visualization.  You  have  to  analyze  the  data 
along  the  function  points.  What  are  the  heuristics,  how  do  you  do  that?  There  is  something  about 
the  visualization,  about  the  human  eye  making  a snap  decision,  that  a program  is  going  to  find 
very  difficult.  I agree  with  you,  but  I don’t  know  how  to  do  it,  as  a software  engineer. 

ESTERLING:  I think  that  you  need  to  model  the  entire  process.  Data  at  a single  point,  a yes  or 
no  there,  depends  on  what  process  you  used  to  machine  that  part  at  that  spot,  what  errors  or 
combination  of  errors  come  into  play.  At  any  time  you  look  at  a plot  of  3-D  points,  not  2-D 
points  to  make  a decision,  it’s  much  better  to  include  the  part  program.  I showed  some  plots 
yesterday,  where  basically  you  feed  in  your  as  designed  data,  in  your  part  program,  you  feed  in 
your  error  model,  and  come  back  with  the  estimate  of  your  part. 

WELSCH:  You’re  doing  it  through  a visualization  program. 

ESTERLING:  No,  the  pretty  pictures  just  help  you  get  funded.  The  software  can  tell  you  where 
the  worst  point  is,  or  the  depth  of  the  gauge  and  its  (x,y,z)  location.  It  doesn’t  have  to  be  pretty 
pictures,  the  pretty  pictures  are  what  sells. 

PATTERSON:  I think  we  have  a good  example  of  the  value  of  why  we,  at  least  started  out,  are 
here.  There  are  differences  in  how  we  use  the  data  and  what  the  applications  are,  and  what  we 
think  our  controllers  are  going  to  do.  However,  the  fact  is,  that  we  aren’t  going  to  be  able  to  do 
any  of  that,  unless  we  can  move  the  data  between  pieces.  What  we  end  up  doing  with  the  data 
will  differ.  The  applications  are  different,  operations  are  different,  and  some  will  make  fortunes. 
No  one  will  be  able  to  do  it  unless  we  can  move  the  data  around.  I’m  really  interested  in  seeing 
how  Alkan  Donmez  is  going  to  get  us  there  to  actually  be  able  to  move  the  data  around. 

DONMEZ:  That’s  a very  good  point.  We  should  not  be  looking  into  the  details  how  we  will  use 
the  visualization  tools,  at  this  stage.  What  we  should  be  concentrating  on  is  what  type  of  data 
should  we  be  feeding  to  systems  like  visualization.  Let’s  move  on  to  the  road  map  and  then  we 
can  come  back  to  related  discussions  later. 
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Discussions  on  the  Road  Map 


Data  Repository 

DONMEZ:  We  need  to  fill  in  the  blanks  of  our  draft  flow  chart.  The  first  slide  comes  from  Ray 
McClure’s  summary  of  the  last  workshop.  [Slide  12-2].  He  asked  some  key  questions.  We  are 
building  this  program  to  try  to  address  these  issues.  If  you  look  at  the  questions,  the  core  of  the 
answer  is  in  the  data  and  information.  We  are  trying  to  standardize  data/information  so  that  we 
can  share  it  from  system  to  system,  tool  to  tool,  or  company  to  company.  We  have  to  have  tools 
to  help  us  with  tolerance  budgeting,  machine  simulation,  process  simulation,  inspection  planning 
and  simulation,  performance  tracking  of  the  machine  to  aid  in  maintenance  activities  [Slide  12-3]. 
We  have  talked  about  these  tools  in  past  meetings.  If  we  need  all  of  these  tools,  how  do  we  get 
them?  We  already  identified  that  we  need  a data  dictionary,  standard  file  formats,  information 
models,  and  we  need  a repository  for  all  of  this.  In  my  rough  plan,  we  have  to  get  there  this  year. 
We  can’t  delay  any  longer.  We  have  been  talking  about  these  ideas  for  about  a year  and  a half 
now.  By  the  way,  our  fiscal  year  is  from  October  to  September,  so  we  are  already  into  fiscal  year 
’98  (FY98).  By  the  end  of  September,  I would  like  to  see  that  we  have  formats  and  information 
models  for  specific  sets  of  experiments,  and  we  should  bound  that  for  3 axis  machines.  In  order 
to  get  there,  I need  participation  from  all  of  you.  We  have  a rough  draft  of  the  data  dictionary  that 
Hans  Soons  presented  yesterday.  What  we  need  is  for  the  consortium  members  to  start  looking  at 
the  dictionary.  I’d  like  to  get  the  comments  and  inputs  back  as  soon  as  possible. 

WELSCH:  Currently  we  have  examples  of  the  Renishaw  ballbar  data  in  the  repository.  We 
could  list  all  of  the  different  formats  that  we  would  like  to  see.  Then  ask  the  question  of,  where 
do  we  measure  these?  Does  the  data  dictionary  cover  that  format?  That  might  be  one  way  of 
proceeding. 

SOONS:  I was  thinking  that  we  could  use  a Web  page,  similar  to  the  example  that  we  showed 
yesterday  of  the  machine  tool  data  format,  and  put  up  a sample  set  of  questions.  For  example, 
you  would  answer  questions  like,  (1)  I’m  going  to  do  a ballbar  test,  (2)  I do  have  a calibrator,  (3) 
I’m  going  to  measure  along  one  incline,  and  (4)  I’m  going  to  use  3 axes.  After  a certain  set  of 
questions  is  answered,  the  web  page  could  then  extract  the  attributes  that  were  relevant  in  that 
test.  This  will  give  those  of  you  that  are  already  using  ballbar  tests  and  have  already  started  using 
the  database  a quick  opportunity  to  compare  the  attributes  that  are  currently  in  the  data  dictionary 
to  which  attributes  that  you  are  currently  using  in  a specific  test.  Similarly,  we  are  definitely 
going  to  compare  those  attributes  with  the  data  format.  That  is  one  of  the  things  that  I mentioned 
yesterday,  that  we  want  to  capture  all  of  the  attributes  and  don’t  want  to  lose  any  information  in 
the  current  data  formats,  for  example,  Renishaw.  I will  be  interested  if  anyone  uses  any  other 
software  like  API,  Heidenhain,  and  Renishaw.  If  you  can  send  us  information  on  those  data 
formats,  it  would  be  very  helpful.  I think  that  once  that  part  of  the  web  page  is  up,  then  we  can 
start  getting  meaningful  discussion  on  the  attributes  in  the  data  dictionary.  So  my  proposal  is  to 
put  up  another  web  page,  perhaps  concentrate  on  circular  tests,  and  try  out  that  method  of 
feedback.  I was  getting  the  impression  that  the  alphabetical  list  of  terms  in  the  data  dictionary 
wasn’t  the  best  way  for  the  consortium  to  assess  the  current  attributes  in  the  dictionary.  I think 
we  have  to  develop  the  structure  of  the  dictionary  in  a meaningful  way. 

DONMEZ:  This  is  an  important  point,  because  it  is  very  difficult  to  look  at  and  analyze  the  list 
of  things  in  the  dictionary  in  alphabetical  order.  You  have  to  make  logical  connections  between 
all  of  the  terms.  This  will  help  us  get  the  structure  of  the  dictionary.  You  can  see  which  terms 
are  relevant,  missing,  etc.. 
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HEMMERLE:  Hans,  isn’t  that  further  clarified  then,  because  what  you’re  saying  not  what’s  in 
the  Appendices,  but  what  is  in  the  ASME  B5,  or  just  the  ballbar  by  January. 

SOONS:  I am  talking  about  solidifying  the  attributes  only  for  circular  tests,  as  a starting  point. 
Parallel  to  that,  I think  that  we  have  to  work  on  putting  a more  visual  structure  to  the  data 
dictionary,  so  that  we  know  which  groups  of  attributes  apply  to  which  tests.  The  reason  why  I 
want  to  go  into  specifics,  is  that  we  have  to  gain  experience  by  getting  into  the  details  to  test  out 
the  process  of  formalizing  the  data  formats. 

HEMMERLE:  So  you  want  some  of  the  Appendix  for  the  details? 

SOONS:  No,  just  the  front  section. 

DONMEZ:  Three  axis  machines  are  covered  in  just  the  front  section.  Keep  the  bounds  on  three 
axes  and  learn  as  much  about  the  process  as  we  can  before  we  go  any  further. 

SOONS:  Circular  tests,  B5.57  standard  for  the  lathe,  already  give  you  the  opportunity  to  use 
gridplate,  disks,  and  the  ballbar.  It  gives  you  a lot  of  variation. 

HEMMERLE:  The  only  plate  I know  of  that’s  on  the  market  is  Heidenhain.  So  we  can  just  go 
directly  to  Heidenhain  and  do  that  one.  With  the  ballbar,  there  are  several  vendors. 

SOONS:  The  problem  with  taking  just  the  data  format  from  the  manufacturers,  is  that  you  don’t 
get  all  of  the  information  you  need,  in  general.  For  example,  if  you  look  at  software  that  has 
mostly  been  discussed  here,  it  doesn’t  ask  you  where  in  the  machine  workspace  you  took  your 
test,  it  doesn’t  ask  you  your  tool  vector,  it  doesn’t  ask  you  a host  of  questions  that  you  need  to 
store  other  than  just  getting  plots  or  the  B5  numbers. 

KRULEWICH:  How  far  along  is  the  data  dictionary  for  other  tests?  I’m  asking  because  I’m 
about  to  perform  a number  of  tests  on  our  machine.  If  I had  the  requirements,  I could  incorporate 
those  in  our  software. 

SOONS:  For  the  basic  setup,  everything  is  there.  However,  there  are  some  specific  terms  for 
spindle  error  motions  that  aren’t  included.  That  is  one  example,  there  are  specialized 
measurements  that  aren’t  covered. 

DONMEZ:  I think  everybody  here  probably  uses  standard  measurements  on  their  machines,  for 
example,  linear  displacement  accuracy,  straightness,  angular  errors,  ballbar  test,  etc..  They  are  all 
pretty  much  covered  in  the  data  dictionary.  Therefore,  you  should  be  able  to  start  implementing 
the  dictionary  into  your  measurements,  see  what  the  deficiencies  are,  and  then  give  us  some 
feedback. 

WELSCH:  My  biggest  concern,  is  that  we  get  the  feedback  that  we  need  and  maybe  we  should 
have  another  meeting  soon. 

DONMEZ:  Logistically  and  financially  meetings  are  hard  to  attend.  I would  like  to  get  most  of 
the  feedback  electronically  (i.e.,  through  the  Internet  or  email). 

KITNA:  I can’t  say  that  I’ve  seen  the  NIST/NAMT  site.  I know  Jim  Covington  has  access.  Do 
you  have  anything  that  tells  you  what  new  features  have  been  added  to  the  site,  maybe  a date 
associated,  and  an  index  of  the  site? 


DONMEZ:  That’s  a good  point  and  that  should  be  added. 

COVINGTON:  I’m  not  going  to  be  casually  logging  on  to  see  what  new  has  been  added  onto  the 
site.  I think  all  of  the  consortium  members  should  be  notified  (by  email)  when  any  changes  are 
made  to  the  site. 

KATTER:  Do  we  all  have  access  to  the  page? 

WELSCH:  Almost  everybody  in  here  has  been  added  to  the  list.  If  you’re  not,  come  see  me. 

DAHILIG:  On  the  data  dictionary,  I keep  hearing  what  you  want  us  to  provide  (files,  how  we  use 
data,  file  formats).  We  have  identified  some  standard  tests  and  software  associated  with  those 
tests  (API,  Renishaw,  etc.)  but  don’t  you  think  that  it  makes  sense  to  just  talk  to  Renishaw;  maybe 
they  have  test  procedures  and  methods  of  manipulating  their  data  that  you  could  acquire  and  add 
to  the  data  dictionary.  They  are  the  experts  on  their  systems  and  should  be  able  to  provide  us 
with  some  information. 

DONMEZ:  Renishaw  indicated  that  they  are  interested  in  participating.  They  couldn’t  make  this 
meeting,  however.  In  the  last  meeting,  API  promised  to  give  us  information,  but  we  haven’t 
gotten  that  yet.  Let’s  get  back  to  the  schedule.  We  said  that  the  data  dictionary  has  the 
terminology  for  all  of  the  standard  tests  and  it  will  be  growing.  However,  we  need  feedback  and 
formats,  from  all  of  the  participants,  starting  with  the  circular  tests.  We  would  also  like  to  put  on 
the  schedule  to  acquire  other  types  of  formats,  such  as  linear  displacement  errors,  laser 
interferometers,  and  other  types  of  instrumentation.  I heard  the  January  timeframe  for 
commenting  on  the  data  dictionary  and  then  a final  data  dictionary. 

WELSCH:  We  shouldn’t  use  the  word  “final”  since  the  data  dictionary  will  be  revised  many 
times  after  May. 

DONMEZ:  It  will  be  a living  document  as  other  types  of  tests  are  added.  For  circular  tests,  it 
should  be  in  a final  form.  There  is  a point  where  changes  to  the  dictionary  will  be  minimal. 

KATTER:  How  about  the  word  usable  data  dictionary? 

DEFORGE:  Would  any  visualization  tools  be  of  value  as  part  of  that  data  dictionary?  For  setup 
and  evaluation  tests? 

DONMEZ:  As  far  as  dictionary.  I can’t  relate  dictionary  to  visualization  tools  at  this  time.  Can 
anyone  help  out? 

WELSCH:  When  you’re  looking  at  the  questions  that  we  ask,  we  put  up  diagrams  to  help  people 
know  what  is  going  on;  images  that  show  what  is  being  defined  in  the  dictionary. 

DONMEZ:  O.K.  In  other  words,  you’re  saying  to  include  visualization  in  the  dictionary,  not  to 
include  terms  to  aid  visualization.  I will  put  on  the  schedule  to  have  a usable  data  dictionary  by 
the  April/May  timeframe.  Between  now  and  then,  you  will  get  a “structure”  from  us  and  then  we 
will  see  your  comments  and  iterate  back  and  forth  until  the  April/May  timeframe. 

COVINGTON:  Do  we  see  everyone  else’s  comments? 


66 


DONMEZ:  In  our  website,  everyone  sees  everyone  else’s  comments. 

SOONS:  Like  I said  yesterday,  the  dictionary  will  not  be  in  an  alphabetical  list,  but  will  have 
more  of  a tree-like  structure  to  make  the  terms  relate  to  each  other  in  a more  meaningful  manner. 

DONMEZ:  If  we’re  shooting  for  a usable  dictionary  by  April,  then  the  dictionary  should  be 
restructured  by  January.  We  are  currently  working  on  a limited  set  of  information  models.  We 
have  experts  in  information  models  who  are  working  with  Hans  to  use  this  dictionary  and  try  and 
develop  the  activity  and  information  models.  I hope  that  by  the  time  we  get  to  this  point  we  will 
have  some  useful  information  models  to  proceed  towards  the  structure  of  the  repository. 

WELSCH:  So  far,  I see  in  April  that  we  will  have  a fairly  rigorous  set  of  attributes  for  circular 
tests  by  April. 

DONMEZ:  By  April,  we  should  have  all  of  the  standard  tests  for  3-axis  machines  in  the 
dictionary.  Hans  already  has,  I believe,  about  80%  of  the  required  terminology  (except  for 
spindles)  associated  with  all  standard  tests,  linear  displacement,  straightness,  etc.. 

SOONS:  I have  to  put  a caveat  on  that.  There  are  procedures,  especially  in  the  latest  standards, 
such  as  reversal  procedures  and  such  that  will  not  be  included  by  April.  Also  not  all  cutting  tests 
will  be  included.  The  main  tests  we  are  talking  about  are  Environmental  Temperature  Variation 
Error  (ETVE),  spindle,  laser,  ballbar,  circular,  squareness  by  April. 

WELSCH:  What  formats  besides  circular  tests  are  we  going  to  include  by  April? 

DONMEZ:  Laser  interferometer. 

KATTER:  What  is  the  timeframe  for  the  laser  tests?  Because  the  data  that  comes  in  ffom  the 
laser  tests  has  several  files  associated  with  them.  The  repository  now,  for  the  ballbar  tests,  we  are 
only  uploading  one  file.  Do  you  want  to  develop  a format  where  we  can  upload  several  files  at 
once? 

WELSCH:  It  is  hard  to  say  what  level  of  effort  that  is  going  to  be  required  for  the  forms  for  the 
other  types  of  file  formats.  If  we  are  developing  two  more  like  the  Renishaw  formats,  then  the 
March  timeframe  is  achievable.  If  you  are  talking  about  50  more,  no  way. 

COVINGTON:  We  should  be  looking  at  who  the  primary  users  are  and  which  ones  we  use  the 
most.  Maybe  we  should  do  a survey  to  see  what  types  of  formats  are  most  popular  among  the 
consortium  members. 

DAHILIG:  Now  as  far  as  the  Renishaw  tests  that  Larry  Welsch  was  talking  about  developing  the 
parsers  for,  that’s  fine  for  now.  Nevertheless,  eventually  we  want  Renishaw  and  the  other 
vendors  to  standardize  their  files  because  as  a software  engineer,  we  want  the  data  to  be  generic 
enough  that  we  don’t  have  to  use  a translator. 

WELSCH:  Do  we  at  NIST  need  to  hold  a workshop  on  that  topic? 

DONMEZ:  Larry  Welsch’ s suggestion  of  the  focused  topics  might  be  more  helpful. 
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WELSCH:  We  need  to  prioritize  which  formats  to  finish  by  the  April  timeframe.  By  January  it 
would  be  reasonable  to  pick.  I’ll  say  arbitrarily,  five  other  formats  to  start  working  on  and  finalize 
by  April. 

KATTER:  I haven’t  gotten  to  use  the  repository  too  much.  I know  that  we  can  currently  upload 
data.  Can  we  download  data? 

DONMEZ:  Currently,  we  don’t  have  that  option,  but  it  should  be  included  soon. 

KATTER:  Can  we  get  the  data  back  in  the  same  format  in  which  it  was  uploaded? 
COVINGTON:  What  types  of  data  are  you  interested  in  downloading? 

KATTER:  I guess  a typical  application  that  might  be  possible  is  if  we  were  considering  using  the 
same  type  of  machines  available  to  the  database.  If  we  could  get  that  information  and  use  it  in 
our  virtual  manufacturing  and  simulation. 

WELSCH:  One  of  the  most  straightforward  ways,  if  you  download  the  data  using  ODBC  you 
can  get  the  data  back  in  a standard  format  that  you  could  use  in  Excel  or  a database  such  as 
Access.  You  pose  the  query  on  the  Web  and  then  get  the  data  back  in  either  of  those  formats.  I 
expect  by  the  April  timeframe  that  will  be  the  most  straightforward  way  of  downloading  the  data. 

KATTER:  Now  it  is  easier  to  get  the  data  back  in  the  format  in  which  it  was  sent  so  that  we  can 
use  the  available  software  to  plot  the  data. 

DONMEZ:  I think  the  data  should  be  stored  in  the  central  repository  in  a standard  formats  not 
company  specific  formats. 

SOONS:  I think  you  should  have  the  option  that  allows  for  downloading  in  the  original  format 
because  it  will  take  some  time  to  develop  applications  where  you  can  use  the  data  in  standard 
formats.  So  initially,  we  should  include  the  option  of  getting  the  data  back  in  its  original  format. 

WELSCH:  My  feeling  is  that  it  will  be  much  easier  to  download  the  data  in  tables  since  you  are 
going  to  be  using  queries.  Nevertheless,  we  can  store  the  data  in  the  database  in  both  standard 
and  original  formats. 

KATTER:  Right  now,  we  don’t  have  a standard  format,  and  the  standard  format  is  not  usable 
because  we  don’t  have  the  analysis  tools  to  extract  the  errors. 

COVINGTON:  Right  now  Renishaw  is  a black  box  so  I can  feed  data  back  in  the  package  to  get 
a plot. 

SOONS:  Right  now  when  files  are  uploaded,  the  filename  and  machine  names  are  encoded.  Do 
you  want  operator’s  names  encoded  as  well? 

COVINGTON:  That  was  a question  I was  going  to  ask.  Is  it  our  responsibility  extract  that 
information? 

SOONS:  I thought  that  if  you  are  going  to  be  sending  us  an  enormous  amount  of  data,  perhaps  it 
should  be  our  responsibility  to  encode. 
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DONMEZ:  If  we  change  the  machine  name,  and  then  they  want  the  data  back,  they  wouldn’t 
know  which  machine  the  data  represented. 

COVINGTON:  Could  you  all  build  a table  of  which  parties  submitted  what  data? 

WELSCH:  The  short  answer  is  yes.  We  can  use  some  straightforward  checks.  We  need  to 
implement  some  management  and  security  tools  on  the  server. 

KATTER:  Are  we  going  to  have  the  link  to  the  machine  classification  site?  Will  it  be  our 
responsibility  to  take  out  the  machine  names  and  operators? 

DONMEZ:  We  are  talking  about  two  different  types  of  linkages.  First,  we  will  have  a linkage  to 
the  page  for  machine  classification  so  that  people  can  get  an  idea  of  what  types  of  information 
classify  machine  tools.  Second,  and  more  importantly,  we  have  machine  identification  which 
links  the  particular  data  file  you  are  uploading  to  an  encoded  name. 

DAHILIG:  I don’t  want  to  have  to  keep  track  of  the  encoded  filenames.  The  solution  should  be 
giving  the  data  back  in  an  uncoded  form  only  if  the  party  which  uploaded  the  data  is  requesting 
the  download. 

DONMEZ:  It  seems  more  complicated  from  our  end. 

WELSCH:  I think  you  can  do  that  with  some  generic  capabilities. 

DONMEZ:  We  will  give  our  recommendations  on  the  management  and  security  issues  of  the 
repository  and  then  have  to  get  feedback. 

WELSCH:  I anticipate  having  a white  paper  on  the  management  and  security  issues. 

DONMEZ:  What  other  functionalities  do  we  want  to  see  in  the  repository?  For  example,  we 
have  uploading  and  analysis,  but  we  don’t  have  a simple  straightforward  presentation  of  data. 

COVINGTON:  We  need  that  because  if  we  want  to  detect  any  spikes  as  opposed  to  the  trend  in 
the  ballbar  data,  for  diagnostic  purposes. 

WELSCH:  It  would  be  extremely  straightforward  to  ship  you  the  either  the  raw  files  or  view  that 
your  query  has  produced,  either  numbers  or  graphs  (whichever  is  appropriate)  for  the  data. 

COVINGTON:  Is  there  an  Access  97  viewer?  Does  it  require  that  everyone  have  Access  97  on 
their  machine? 

WELSCH:  I’m  not  sure  of  the  answer  to  your  question.  It  requires  that  they  have  a program 
capable  of  acting  as  a client  of  ODBC.  Windows  3.1  version  will  not  work. 

DONMEZ:  We  have  one  hour  left  and  haven’t  gotten  very  far.  So  let’s  not  talk  about  details  at 
this  point  and  cover  all  of  the  items  and  timeframes  on  the  agenda.  - By  the  end  of  FY98,  I would 
like  to  see  us  upload/download  any  type  of  information.  Incorporation  of  data  analysis  tools 
started  this  year  and  will  go  on  for  some  time.  I don’t  think  we  can  incorporate  all  of  the  analysis 
tools  that  are  needed  by  the  end  of  FY98.  We  haven’t  really  dealt  very  strongly  about  what  type 
of  environmental  information  will  be  associated  with  the  data  that  we’re  incorporation  into  the 
repository.  I noted  the  physical  description  of  the  machine,  we  have  covered  that.  I also  noted 
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uncertainties,  we  need  some  information  about  the  uncertainties  of  the  data  (measurement  results) 
that  we’re  incorporating  so  that  eventually  we  can  use  tools  (as  stated  in  my  previous  slide)  to 
estimate  the  machine  capability  in  a statistical  sense.  I don’t  have  a clear  picture  how  we  can  get 
there  by  the  end  of  FY98.  We  have  some  ideas  that  we  can  incorporate,  but  I’m  not  sure  if  the 
uncertainty  tools  will  be  finalized  by  the  end  of  FY98.  Let’s  move  on  to  data  analysis  tools. 

Data  Analysis 

DONMEZ:  Currently  we  have  some  basic  ballbar  data  analysis  capability,  as  you  have  probably 
already  seen.  Now  we’re  looking  at,  probably  at  least  a two-year  effort. 

WELSCH:  Sometime  in  the  future,  I would  like  to  see  us  being  able  to  upload  data  for  tools  like 
N-See  and  Deneb.  I’m  not  sure  how  to  capture  that  at  this  point. 

SOONS:  What  I’ve  heard  at  this  workshop  is  that  people  want  to  do  some  timeline  comparisons. 
As  far  as  diagnostics  go,  somebody  mentioned  earlier,  Renishaw  has  some  kind  of  diagnostics. 
We  have  some  diagnostics.  In  terms  of  timeline  analysis  capability,  we  currently  don’t  have  any 
capability. 

WELSCH:  Related  to  that,  Deneb  needs  some  form  of  numbers  to  implement  in  their  software. 

DEFORGE:  That’s  why  I was  asking  yesterday,  about  visualizing  data  from  simulation.  We 
may  plot  some  points,  that  would  be  one  thing.  But  if  we’re  going  to  actually  change  the 
kinematics  of  the  machine,  that  would  be  another.  That’s  why  I was  trying  to  find  out  how 
people  were  planning  to  use  the  tool,  how  do  you  want  to  visualize  these  databases?  I don’t  think 
anybody  knows  the  answer  to  this  question. 

DONMEZ:  How  about  if  I say  modeling?  Modeling  can  be  very  simple,  you  can  take  just  one 
axis  and  just  fit  a polynomial  around  the  data  to  represent  the  errors.  Or  combine  several  errors 
into  one  volumetric  performance  type  of  model.  Or  we  can  be  very  extensive  and  incorporate 
kinematics. 

DEFORGE:  These  are  all  interesting  ideas,  and  they’re  all  conceptual  at  this  point.  We  need  to 
determine  what  is  realistic  for  computation  and  speed. 

DONMEZ:  There  are  many  efforts  going  on  at  Caterpillar  and  Boeing,  of  comparing  machines 
and  comparing  machines  over  time.  Do  you  think  these  tools  will  be  available  in  the  repository 
eventually?  What  is  the  company  policy  around  that?  If  NIST  is  supposed  to  do  all  of  this 
development,  that  is  a lot  of  work.  What  we  would  like  to  see  is  that  the  generic  models 
developed  in  these  companies  incorporated  into  the  repository. 

DEFORGE:  Some  of  the  activities  that  we  have  going  on  right  now  is  we  don’t  always  get  access 
to  their  algorithms,  we  just  supply  information  to  their  algorithms.  It’s  not  necessary  for  me  to 
have  their  algorithms,  just  a standardization  of  the  data  format.  Then  again,  they  can  supply  me 
with  their  data  from  the  simulation  model.  I don’t  think  we  need  to  know  how  to  manipulate  the 
data. 

DONMEZ:  In  his  presentation  yesterday,  Vivek  was  making  some  charts  about  the  time 
dependency  of  the  machine’s  error  behavior  and  he  also  showed  the  comparison  between 
machines  A,  B,  C,  and  D for  a given  time  frame.  Those  types  of  tools,  obviously,  exist  right  now 
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at  Caterpillar.  I’d  like  to  investigate  how  proprietary  those  things  are  and  the  possibilities  of 
sharing  them  in  this  consortium. 

KATTER:  These  issues  I have  to  consult  with  my  management.  I have  to  find  out  what  you  can 
access  to  and  who  gets  access. 

ESTERLING:  To  answer  you  question  earlier  about  simulation  tools.  The  current  formulas  that 
you  provided  us  to  model  the  turning  operation.  You  have  error  in  X as  a function  in  Z for  2-D 
systems  it  is  in  parametric  format.  If  the  data  is  not  available  in  parametric  functions  and  a 
generalization  into  3-dimensions,  then  as  a function  of  (x,y,z)  and  (i,j,k)  as  a function  of  all  of 
your  parameters.  That  would  be  the  most  convenient  for  me,  the  one  easiest  for  me  to  implement. 
If  the  data  were  presented  in  some  numerical  formula,  errors  that  you  expect  for  a given  type  of 
tool  mode  at  different  locations  and  it’s  O.K.  to  interpolate  between  the  two,  then  that’s  a smart 
program,  and  not  a barrier.  We  can  take  both  numerical  and  parametric  data. 

KRULEWICH:  You  are  not  prepared  to  take  straightness,  position,  and  other  types  of  data  like 
that? 

ESTERLING:  No.  I don’t  want  to  take  raw  data. 

WELSCH:  How  would  you  like  to  see  the  parametric  equations  represented? 

ESTERLING:  I don’t  care,  just  write  the  code. 

SOONS:  Somebody  has  to  build  the  kinematics  model  into  the  error  parameters  taken  for  that 
specific  machine.  Different  people  model  the  machines  in  different  ways.  So  it  is  the 
responsibility  of  the  person  who  took  the  error  data  provide  information  for  the  kinematics  model 
of  their  choice.  We  have  to  have  the  locations  of  the  coordinate  frames,  the  signs. 

DONMEZ:  We’re  going  back  to  the  sign  conventions,  which  we  haven’t  covered  yet. 

WELSCH:  My  question  is  to  you  Hans,  why  don’t  we  have  the  person  taking  the  data  translate 
their  parametrics  using  their  kinematics  equations?  That’s  basically  what  I heard  Don  say,  that  is, 
give  me  the  translated  data  in  a form  that  I need. 

DONMEZ:  I want  to  make  a simple  proposal  for  the  sign  conventions,  since  we  need  to  address 
that.  Why  don’t  we  just  use  the  standard  EIA267? 

SOONS:  In  the  data  dictionary,  I basically  wrote  it  so  it  doesn’t  force  you  to  take  any  sign 
convention.  The  sign  convention  will  be  treatable  from  the  data.  The  reason  that  it  is  written  that 
way  is  because  there  is  a lot  of  old  data  out  there  that  wasn’t  performed  via  a standard  and  there  is 
still  is  a lot  of  discussion  going  on  about  sign  conventions.  I don’t  think  this  is  the  proper  forum 
to  discuss  sign  conventions.  There  is  currently  some  work  in  the  B5  standard. 

HEMMERLE:  I think  we  should  address  the  sign  issue. 

DONMEZ:  The  sign  issue  certainly  effects  our  repository.  However,  I think  the  solution  that 
Hans  came  up  with  is  that  if  you  have  a sign  convention,  then  put  it  in.  I think  we  should  have  a 
default  sign  convention  eventually.  My  position  is  that  there  is  a standard  that  people  already  use 
for  axis  nomenclature.  It  is  recognized  nationally  and  internationally. 
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HEMMERLE:  The  EIA-RS267A  standard  did  not  address  rise  and  fall,  side  to  side.  Rise  and 
fall  was  in  and  out  of  a way  plane;  not  an  axis  direction.  We  can  go  that  way  but  when  I say 
positive  it  should  be  rise. 

DONMEZ:  When  you  say  rise  and  fall,  you  are  talking  about  straightness  in  horizontal  and 
vertical  directions? 

HEMMERLE:  Yes.  Rise  and  fall:  positive  was  away  from  the  way  plane,  negative  was  into  the 
way  plane.  Put  a way  system  like  that  on  a horizontal  milling  machine,  positive  away  from  the 
way  plane  is  negative  in  the  z direction.  Those  were  never  described  in  the  standard. 

DONMEZ:  Let’s  talk  about  3 axis  machines  which  are  very  well  defined,  whether  the  part  is 
moving  or  whether  the  tool  is  moving.  The  basic  coordinate  frames  are  well  defined.  If  I’m 
looking  at  one  axis  motion  and  if  I’m  looking  at  the  straightness  of  that  motion,  and  certainly  I’m 
looking  at  straightness  in  one  plane  which  has  the  other  axis  already  defined  and  straightness  in 
the  horizontal  of  the  other  axis  which  was  also  defined.  So  if  I can  define  my  straightness  along 
with  the  main  sign  of  the  axis  direction,  then  what  am  I doing  wrong? 

HEMMERLE:  If  your  dictionary  has  that,  then  I would  certainly  buy  it. 

DONMEZ:  Let’s  put  the  B5  standards  aside  for  now.  If  we  just  stick  with  the  nomenclature 
standards,  then  it  is  unambiguous  in  my  view.  Except  if  you  have  a rotary  head,  then  you  have  to 
think  about  it  a little  bit  more.  But  first,  let’s  address  the  straightforward  3-axis  machines,  which 
is  unambiguous. 

HEMMERLE:  From  the  mathematical  world. 

DONMEZ:  If  you  are  trying  to  have  an  intuitive  interpretation,  then  you  have  to  think  a little  bit 
more. 

KRULEWICH:  I think  where  it  is  still  ambiguous,  yes  we  always  know  what  is  positive  (x,y,z) 
but  not  when  your  part  is  moving.  If  you’re  trying  to  figure  out  if  the  part  is  moving  in  the 
positive  x or  y and  you  are  looking  at  the  part  from  a stationary  point,  you  get  one  answer.  But  if 
you  are  sitting  on  the  part,  you  get  a different  answer. 

DONMEZ:  You’re  trying  to  have  an  intuitive,  on-the-spot  evaluation.  The  only  reason  for  these 
complications,  and  the  same  argument  goes  for  the  B5  committee,  is  that  we  want  to  generalize 
some  intuitive  interpretation  for  a variety  of  different  configurations.  I don’t  think  that  is  easy, 
that’s  why  we  are  having  so  many  problems. 

KRULEWICH:  I guess  the  part  has  a prime  axis. 

DONMEZ:  If  the  part  is  moving  then  use  the  prime  axis,  but  your  positive  x is  still  positive.  It 
makes  the  standardization  simplified,  but  it  makes  intuitive  interpretation  a little  harder.  We  have 
to  make  sacrifices  somewhere.  I think,  going  back  to  the  NIST  approach,  I think  that  the  sign 
convention  is  incorporated  into  the  dictionary.  But  for  the  future,  we  should  think  about  a default 
case,  which  is  in  the  existing  standards  EIA-RS267A  or  ISO  841,  which  are  both  the  same. 

KRULEWICH:  So  as  it  is  now  in  the  dictionary,  the  user  has  to  specify  the  sign  convention?  If 
we  were  going  to  interface  with  the  model,  the  user  would  have  to  process  the  data  accordingly? 
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SOONS:  I still  have  to  work  on  some  aspects  of  the  dictionary  with  respect  to  sign  convention. 
For  example,  if  you  were  doing  a laser  measurement,  and  the  error  was  in  the,  say,  positive  z,  it 
depends  on  which  direction  your  measurement  was  taken.  So  basically,  no  matter  how  you 
choose  your  sign  convention,  you  have  to  incorporate  it  so  you  can  retrieve  the  data  correctly.  I 
don’t  think  it  is  a good  idea  to  force  definitions. 

DONMEZ:  Some  of  these  analyses  will  depend  on  others.  For  example,  how  are  you  going  to 
perform  time  dependent  analysis  without  some  parameters  extracted  from  the  data?  You’re  not 
going  to  just  overlay  plots  to  do  time  dependent  analysis. 

SOONS:  You  may  just  want  to  compare  the  current  performance  with  previous  performance  by 
overlaying  the  plots. 

COVINGTON:  All  we  are  interested  in  is  seeing  changes  in  the  system  over  time,  so  we  will 
want  to  just  overlay  the  ballbar  plots. 

DONMEZ:  It  is  a good  way  to  look  at  the  plots,  but  you  may  also  want  to  look  at  the  numbers. 
For  example,  straightness  number  of  ABC  over  time,  you  plot  that  and  see  what  the  trend  is.  In 
order  to  get  those  numbers  you  have  to  rely  on  this  type  of  analysis:  take  the  data  and  fit  it,  come 
up  with  the  single  number  or  equation  and  so  forth. 

COVINGTON:  I am  not  a metrologist,  so  I don’t  really  understand  the  example. 

DONMEZ:  For  example,  if  my  straightness  is  changing,  something  like  that,  I can  fit  the  data  to 
polynomial  equation,  and  track  the  maximum  number  over  time;  a very  rough  idea. 

COVINGTON:  I was  hoping  we  could  talk  about  some  data  analysis  i.e.,  extracting  points  from 
a graph.  What  about  dynamic  graphics  on  the  web? 

LING:  I believe  Excel  will  allow  you  to  extract  points  from  graphs.  I think  with  graphics,  it 
might  be  better  to  download  the  data  to  your  machine  and  use  your  own  graphical  analysis 
package. 

KRULEWICH:  I was  hoping  we  would  be  able  to,  at  least,  select  columns  of  data  and  then  plot  it 
just  out  of  the  repository. 

DONMEZ:  Instead  of  just  analysis,  I’d  like  to  see  viewing  of  data  and  that’s  just  to  plot  it  to  see 
what  it  looks  like. 

WELSCH:  I think  it  would  be  a good  idea  to  just  get  the  most  common  plots  that  everyone  likes 
to  see  and  have  the  code  available  for  viewing  on  the  web.  We  have  a dynamic  plot  already  on 
the  web  with  the  ballbar  data. 

DONMEZ:  We  should  be  able  to  do  that  with  MATLAB  or  a similar  package. 

COVINGTON:  I’d  like  to  talk  about  comparisons  of  machines  over  time  as  well  as  machine  to 
machine  comparisons.  I don’t  know  if  that’s  a subset  of  the  modeling? 

DONMEZ:  Yes.  When  you  do  comparative  analysis,  you  can  do  it  along  a time  frame  or  along 
machines. 
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COVINGTON:  What  would  a simple  tool  for  that  be?  Some  simple  way  to  compare  your 
machines. 

KRULEWICH:  You  could  do  some  time  dependent  analysis  without  the  modeling,  like  what  you 
just  drew.  Rather  than  curve  fitting,  just  record  the  maximum  value  of  your  data. 

DONMEZ:  That’s  true,  but  then  you’re  sensitive  to  noise  and  especially  for  the  straightness,  you 
need  some  pre-analysis,  fitting  or  smoothing.  Any  other  basic  analysis  tools  that  we  need  to  get 
us  there  in  about  a two-year  time  frame? 

KRULEWICH:  If  you  just  did  the  modeling,  that  would  be  an  amazing  tool. 

DONMEZ:  We  didn’t  really  specify  what  modeling  we  were  going  to  do,  but  we  can  cover  a lot 
of  ground.  I don’t  think  we  can  cover  everything  in  modeling  in  a two-year  time  frame. 

KRULEWICH:  I guess,  two  years  down  the  line,  if  the  controllers  are  ready  to  truly  compensate 
a machine,  then  they  can  use  that  package.  Then  you’ll  need  the  controller  people  involved  with 
the  repository. 

DONMEZ:  For  now,  I’m  not  considering  the  kinematics  modeling  as  a part  of  this.  I’ll  leave  the 
kinematics  modeling  for  software  developers,  simulation  tools  and  such.  What  I need  here  is  to 
be  able  to  understand  what  the  raw  data  means;  that  type  of  model.  Next  is  simulation  tools,  Don 
has  already  given  us  a demonstration  of  one  package.  What  I mean,  is  the  integration  of 
simulation  tools  in  the  repository?  Don  should  be  able  to  access  the  repository,  get  the 
information  that  he  needs  and  begin  to  use  his  simulation  tools.  That  smooth  transition,  I’d  like 
to  see  happen  by  FY99. 

ESTERLING:  If  the  simulation  tools  exist  today,  then  what  is  there  to  transition  to?  The  tools 
that  you  need  don’t  exist  today. 

DONMEZ:  In  the  time  frame  that  I am  talking  about,  the  tools  should  be  in  existence  at  that 
time.  Based  on  all  of  these  discussions,  you  simulation  tool  developers  will  go  back  home  and 
develop  tools  that  are  more  extensive.  I’m  saying  at  that  point  (two  years),  we  should  have  a 
seamless  interface  between  the  repository  (all  the  information  that  we  are  collecting  and 
generating)  and  simulation  tools.  That  is  my  target. 

DEFORGE:  What  we  have  to  look  at  during  that  development  is  that  we  need  a business  case  to 
start  doing  that  development.  We  need  a justification  that  people  will  buy  the  product.  I certainly 
can’t  get  the  product  developed  if  people  aren’t  going  to  buy  the  product.  In  terms  of  the  two- 
year  time  line  to  develop,  we  also  need  to  spend  some  of  that  time  making  sure  the  business  base 
will  be  there. 

DONMEZ:  You  are  at  least  getting  some  feel  for  what  these  people  are  wanting  for  their 
applications?  You  have  a good  grasp  of  what  your  capabilities  are.  I’m  talking  about  the  near 
future,  where  you  know  the  market  situation,  you  know  the  technology  potentials,  and  now 
you’re  learning  what  these  customers  (at  least)  need.  Therefore,  by  that  time  you  should  be  able 
to  have  some,  at  least,  prototype  tools  that  we  can  start  checking  to  see  if  we  can  have  seamless 
interaction  with  the  repository.  But  as  far  as  NIST  effort  is  concerned,  are  there  any  areas  where 
you  would  like  to  see  us  concentrating?  So  basically,  it’s  an  assignment  for  you  software 
developers  to  be  there  by  the  end  of  1999. 


74 


Performance  Tracking  Tools 


Performance  tracking  tools  are  somewhat  an  extension  of  time  dependent  analysis.  [Slide  12-5].  I 
wasn’t  quite  sure  how  extensive  we  wanted  to  be  in  that  analysis.  Starting  in  FY98,  this  year,  it 
could  go  a couple  of  years  effort,  depending  on  the  type  of  things  we  want  to  do  there.  I think  it 
is  an  important  tool  that  people  need.  The  second  item  there,  capability  evaluation  tools;  from  a 
statistical  point  of  view.  I keep  bringing  this  up,  but  I don’t  see  much  reaction  to  this  topic.  I 
don’t  know  if  it  is  not  important  at  all  to  you.  Everybody  talks  about  wanting  to  be  a 6a 
company,  what  do  you  mean  a 6a  company?  If  you  don’t  know  the  capability  of  your  machine, 
how  can  you  tell? 

COVINGTON:  I’ll  give  you  a quick  answer  to  your  question  of  why  I haven’t  responded.  We 
have  so  many  parts  Cpk  is  unrealistic  unless  you  have  some  way  of  tracking  those  numbers. 

DONMEZ:  I use  the  term  Cpk  for  a lack  of  a better  term.  Somehow,  if  you  have  a machine,  how 
can  you  put  some  statistical  bounds  around  what  you  can  estimate  the  capability  of  the  machine 
is?  The  machine  is  certainly  deterministic,  but  there  are  apparent  nonsystematic  problems 
associated  with  things  that  you  don’t  characterize  and  you  don’t  measure.  That  puts  some 
uncertainty  in  the  evaluation  of  your  machine’s  actual  behavior.  If  you  spent  a whole  year  on  that 
machine,  you  would  find  out  many  cause  and  effect  relationships  and  could  characterize  that. 
That’s  what  everybody  means  by  deterministic  machines.  If  you  only  have  one  day  to  find  out 
how  your  machine  behaves,  there  is  some  uncertainty  in  the  understanding  of  that  behavior.  The 
machine,  over  time,  will  change  as  a response  to  environmental  characteristics,  and  you  are 
capturing  some  of  those  characteristics  by  going  through  the  standard  measurements.  What  is  the 
implication  of  the  standard  measurements  as  opposed  to  the  actual  capability?  And  what  are  the 
uncertainties  that  you’re  introducing  or  overlooking  when  you  evaluate  that  machine’s  capability. 
That’s  what  I’d  like  to  capture. 

COVINGTON:  I think  that’s  a capability  that  we’ll  eventually  need,  but  it’s  pretty  far  down  the 
line. 

DONMEZ:  You  all  have  been  asking  for  a 5-10  year  road  map,  so  I’m  trying  to  look  ahead. 

SOONS:  Perhaps  you  are  already  working  with  some  of  the  issues  related  to  Cpk.  We  are  trying 
to  translate  part  inaccuracies  to  the  machine  performance  by  collecting  data  over  time  and  getting 
the  statistical  information. 

DONMEZ:  With  the  kind  of  data  that  we  are  and  will  be  collecting,  you  should  be  able  to  deduce 
some  information  about  your  machine’s  capability.  We  don’t  know  how  to  do  that  yet. 

COVINGTON:  If  it  is  a goal,  we  will  definitely  support  that  goal. 

DONMEZ:  So  maybe  it  is  too  optimistic  to  expect  something  by  the  year  2000. 

COVINGTON:  Maybe  not,  if  we  can  make  things  happen. 

DONMEZ:  If  everybody  starts  thinking  in  that  direction,  maybe  we  can  come  up  with  some  nifty 
solutions. 

Inspection  Analysis  Tools 
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DONMEZ:  You  have  already  seen  IC AMP’s  work.  There  are  already  some  work  going  on  in 
inspection  analysis.  What  I’m  hoping  is  that  we  can  integrate  inspection  analysis  systems  into  the 
repository,  so  we  can  get  closer  to  the  overall  virtual  machining  and  virtual  inspection  systems.  I 
have  set  a time  of  FY01. 

COVINGTON:  Did  you  have  anything  about  new  test  methods  and  the  analysis  of  three  axes 
machines? 

DONMEZ:  We  need  to  look  at  new  test  methods  and  the  data  associated  with  those  methods.  I 
think  there  are  many  ongoing  efforts  at  various  institutions  and  we  should  certainly  try  to  get  that 
information  to  see  how  it  fits  into  our  model  of  things. 

Dynamic  Models 

DONMEZ:  Of  course,  a few  years  down  the  line  we  need  to  look  at  the  dynamics  (FY02). 

We’ve  been  looking  at  the  quasi-static  errors,  machines  and  how  they  relate  to  the  parts,  things 
like  that.  But  we  never  have  addressed  the  issue  of  how  we  can  integrate  dynamics  into  the 
repository.  What  do  we  store?  Do  you  store  the  (impact)  hammer  test  results  for  a baseline 
machine?  If  so,  how  do  you  do  that,  the  frequency  domain  or  other  domain? 

SOONS:  What  about  the  loaded  tests? 

DONMEZ:  I had  that  in  mind,  but  didn’t  put  it  down.  It  should  be  accomplished  in  the  nearer 
term  than  FY02.  Of  course,  when  we  talk  about  modal  machine  tests,  there  are  no  standards  in 
existence.  It  is  going  to  be  hard  to  define  a standard  data  format  in  the  dictionary  if  you  don’t 
have  a standard  test.  So,  it  is  something  we  have  to  keep  in  mind  and  hopefully  drive  the  B5 
committee  to  come  up  with  some  standard  tests.  But  we  have  some  standards  in  place  to  look  at 
machine  dynamics,  to  eventually  integrate  some  machine  formats  into  the  repository. 

Machine  Process  Models  Integration 

DONMEZ:  Of  course  the  ultimate  in  virtual  machining  capability  is  to  integrate  the  machine 
process  models  into  the  repository.  I think  it  is  very  optimistic  to  put  a six-year  time  frame  on 
this  goal  (FY03).  But  at  least  we  should  keep  these  ideas  and  targets  in  mind  and  have  some 
hope  of  getting  there  someday. 

KITNA:  What  is  the  prioritization,  what  is  the  visibility  for  progress?  Could  you  have  a Gantt 
chart  and  some  means  of  telling  us  about  updates  with  who  has  signed  CRADAs,  etc.?  It  would 
help  us  a great  deal,  if  there  were  prioritization  of  essential  elements  as  we  move  forward.  What 
are  the  essential  milestones? 

DONMEZ:  I think  we’ve  pretty  much  covered  the  first  year.  We  can  go  back  to  that  again. 

Some  of  the  essential  milestones:  1.  April  ‘98  have  useable  data  dictionary  for  all  basic  tests,  2. 
December  ’97  Security  and  Management  Issues  of  web. 

KITNA:  You  had  analysis  tools  listed  and  a time  line  of  when  the  goal  of  having  a usable  set  of 
tools.  It  would  be  beneficial  to  have  an  incremental  delivery  of  tools,  maybe  if  there  are  3 or  5 
that  come  up,  but  don’t  wait  for  the  delivery  date  to  deliver  those  tools,  so  alert  us  of  any  progress 
and  status  of  NIST  site. 

HEMMERLE:  In  your  road  map,  you  need  to  focus  on  getting  more  people  involved. 
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COVINGTON:  By  more  people,  do  you  mean  more  people  out  of  the  same  organizations  or 
different  companies? 

HEMMERLE:  Different  companies,  or  more  potential  users  to  get  involved. 

KRULEWICH:  What  about  machine  tool  companies? 

DONMEZ:  Machine  tool  companies  are  very  reluctant  to  participate  in  these  types  of  efforts. 
The  only  hope  is  maybe  the  big  users,  if  there  is  a push  for  them  to  collaborate.  If  we  get  too  big 
then  we  have  to  compartmentalize  the  discussions.  We  could  certainly  use  the  automotive 
perspective.  We  don’t  currently  have  any  participants  from  that  industry. 


SOONS:  Unfortunately,  we  had  a scheduling  conflict  with  the  ASME  conference  for  this 
workshop.  It  would  be  nice  to  get  Renishaw  involved  as  well. 


This  concludes  the  third  workshop. 

Editor’s  Note:  The  time  line  resulted  from  the  discussions  are  presented  in  Appendix  II. 
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Appendix  I - Presentation  Slides 
1.  Alkan  Donmez 
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Project  Summary 

Goal:  To  develop  tools  necessary  to  enable  virtual 
manufacturing 


• Data  Dictionary  and 
Information  models  for 
machine  tool  performance 
data 

• Distributed  repository  of 
data  and  analysis  capability 

• Low  order  generic  machine 
performance  models 
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Summary  of  Last  Workshop 

• Machine  tool  metrology  information 
modeling 

• Data  requirements  and  formats 

• Web-based  experimental  Repository 

• Interim  machine  tests 

• Simulation  tools 

• Representation  of  machined  part 


Needs 

Slide  1-6 

Critical  Issues  Raised 

• Machine  capability  evaluation 

• Process  variability  evaluation 

• Need  for  capturing  complete 

• Make/buy  decision  tools 

measurement  information 

• Machine  performance  tracking 

• Sign  conventions 

♦ Capacity  planning 

• Frequency  content  of  performance  data 

* Maintenance  planning 

• Machine/process  interaction 

• Inspection  planning  and  algorithm 

-Fixturing,  material  properties,  dynamics 

evaluation 

• Machine/environment  interaction 
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Slide  1-7 


Slide  1-8 


Slide  1-9 


Slide  1-10 

Critical  Issues  Raised 

Action  Items 

• Physical  description  of  machine 

• Economic  performance  info  (scrap  rate) 

• Create  Data  Dictionary 

• Ability  to  store  model  coefficients 

• Start  moving  data  into  Repository 

• Visualization  for  maintenance 

• Establish  a Consortium 

• Translation  of  info  into  simple,  concise 

• Establish  electronic  communication 

results  to  present  to  decision  makers 

• Develop  a road  map 

• Performance  tracking  by  part  probing 

Slide  1-11 

Critical  Issues  Raised 

Objectives  of  This  Meeting 

• Graphical  representation  of  machined 
part 

• Need  for  high  level  info  for  simulation 

• Three  approaches  to  simulation 

- part,  machine  and  part,  machine  only 

• Extent/accuracy/speed  compromise 

• Information  in  three  categories 

- machine,  instrument,  measurement  related 

• Review  progress  of  participants 

• Review  Data  Dictionary 

• Review  status  of  Repository  and 
analysis  tools 

• Review  simulation  tools 

• Review  road  map  and  future  work 

Consensus 

Virtual  Mfg  is  end  goal,  but 

• Keep  the  scope  restricted  to  machine 
tool  errors  and  translation  of  these 
errors  to  part  errors 

• Concentrate  on  information  models, 
database  design  and  file  formats 
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2.  Martin  Kitna 

Slide  2-1 

_NISTWofkshO£_ 


November  20.  1997 


JBrajFfAfG 


Slide  2-4 


Boeing  Corporation  201 6 Vision 

A jujrrafior  Str*tog»*3  Forum  Jin*  24  1 997 


Factory  Computing  Architecture  - 
A Key  Component  of  Boeing’s  2016  Vision 


NIST  Workshop  November  20. 1997 

Prepared  by: 

Factory  Computing  Architecture  Core  Team 
Presented  by: 

Martin  R.  Kitna,  FCA  Measurement  Domain  Architect 


• integral**} 

Aerospace 

Company 

* . GioOai  (I'TtcmaDonai; 

Ertorprtsc 

• Competencies 

• Largo  scale  compto* 
systems  integration 

* • Lean,  eftioort  design 

and  production  sysfoms 

• Detailed  customer 
*no wedge  4 focus 


rlty  Shareholder  Va/u, 


People 

• Sow  pocoo  cinriiny 

• A*tr»n  p*opM  <nr»*«y 

• ExpOC  mvertwrent  ana 

6ccou  otatiU  y 

• Worv  cooporalnoty  with  Ur»on» 

• Compensate  at  rr^nm  rain  win 
opponurrty  to  cam  more  baaed  on 
company  success 

• Smw  to  balance  oeopie-*  neeos 

• Our  oaoc-a  ad  rafl*C  Our 
paograprsc  Oiveraty 

• Promote  poopic  Urty 

• Provide  opportunity  lor  Uc-tong 
learning 

• Wetness  both  aahm  and  o urs-oe 
tfte  company 

* • Managemenrs  role  is  to  supoort. 
remove  roadblocks.  ano  tacWala 


• Small  operanng  groups 

* • Small  Duirau  units 

• • SmaS  central 

organ^aaon  prowd-ig 
crocal  integration 

• Shared  Resources 
orgarwa&on 

• Design  4 crooucbon  24 
hrsTday  - 7 dayVw**k 


Slide  2-2 


£ 


AI7f/iW 


Factory  Computing  Architecture  Users  Coherence 


Factory  Computing  Architecture  Is  Strategic 


•'A  set  of  computing-based  strategies  : 

• Enabling  Factories  Implement  BCAG  Initiatives 

• Assure  factory  equipment  investments  have 
flexibility  to  change 

•Assure  connectivity  to  upstream  and  downstream 
data  and  functionality  for  future  Integration 

'These  strategies  are  captured  In: 

•To-Be  Architecture  Framework 
•Technical  standards 

•Transition  plans  -Business  & Tech  Forecasts 
•Models  capturing  integration  points  allowing 
reuse 

*Thls  architecture  Is  deployed  thru  a common 
“Factory  Upgrade  Process" 


Slide  2-5 


2016  Vision  ■ Manufacturing  Strategy 


♦ Global  enterprise 

♦ Lean,  efficient  design  & production 

♦ Small  business  units 

♦ Small  central  organization  providing  critical  integration 

♦ People  and  cultural  change:  Inter-team  communication 


Slide  2-3  Challenge  to  User  and  Supplier  Community 

Aowmaaon  Strnleg.es  Foggn June  24.  1997 

♦ The  Boeing  Company  is  developing  an 
integrated  factory  computing  architecture 

- It  will  change  the  way  we  do  business  with  our 
supplier  community 

♦ User  Community  - Team  to  define  approach  to 
evolve  to  common,  open  systems 

♦ Supplier  Community  - Incorporate  products  into 
your  business  strategies  supporting  our  transition  to 
common,  open  systems 


Slide  2-6 


^’27/r/A'/7 


Cross  Functional  Integration:  IPTs  & Process  Disciplines 

Discipline  Owners 


Factory  Upgrade  Process 


LMA  Capacity  Analysis  Mew  Equip,  Intro,  AcqJMcxl 


tnaaoted-Eadiisl  Team 
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Slide  2-7 


Slide  2-8 


Slide  2-9 


Cross  Functional  Integration:  IPTs  & Process 
Disciplines 

Automation  Stratagws  Forum  Juna  24. 1 997 


Integrated  Product  Teams- 


Stuanon  and  Viaon 


Slide  2-10 


Factory  Computing  Architecture  Focus 

Automation  Sir 


Slide  2-11 


Existing  Factory  Situation 

Automation  Stratopo*  Fonxn  Junm  24. 1997 


Scooa 


BCAG  Strategies 


Antiiturtini  tli'nwrMK 
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Slide  2-13  Emerging  Business  Processes  Slide  2-16 


Aimftwcium  Simturtw* 


Integration  across  Factory  Domains  is  Critical 

Automation  Strategies  Fonjn  June  24. 1997 


Slide  2-14 


Upgrading  the  Factory  lor  Vision  2016 

Automation  Stroogw*  Fonjm  Juno  24.  1997 


Slide  2-17 


Engnaenng  D*»gr>  and  BvM 


Should-Se  Factory  Upgrade  Process 


Software  Devon  Budd  / tntegraaon 


5V  t" 


Enqin— nng  Dw/i  and  Build 


ArcJvtacture  Strateo>M 


Technical  and  Product  Standards  are  where  we  start 

Automation  Strategies  Forum  June  2«.  1997  4 


Standard* 


Functional  Standards 


Architecture  Strategies 


Slide  2-15 


Benefits  of  Factory  Computing  Architecture  Slide  2-18 

Automation  Stratape*  Forum  June  24.  1 997  "ur,I“**  ’ 


Activity-centered  Domain  Analysis  Integrates  Across 
Factory  Domains 
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Slide  2-19 


Slide  2-20 


Slide  2-21 


factory  Computing  ArCfM»*ctu'«  llxr* 


^/ZfAVC” 


Factory  Corripufcfig  Ar,cft*»ct\x»  U*wm  Conference  Oe**>»r2i 


BCAG  Factory 


•Assembly 
•fatwicaoon 
•Wtehrta 
ISOS  Groups 
•Pugel  Sound 
•St.  Louis 
•Long  Beach 


Factory  "Culture" 

Differing  ways  to 
support  the  Factory' 

Iggftnsal  Perspectives 

Numerical  Control 
Measurement 


Diverse  Interests  Coming  Together* 


Common  Production 

Strategy 

Understanding 


Manufacturing  Process  Control 
Computing  Services 


Expectations  for  1997  and  1 998 

AjKmaaon  Stratg^M  Forum  .Arne  24.  1997 


Slide  2-23 


♦ Establish  integrated  architecture  and  related 
Infrastructure 

♦ Team  with  user  community  (automotive  & others) 

♦ Develop  a multi-year  architecture  deployment 
plan 

♦ Convey  Boeing  computing  strategies  and 
direction  to  Supplier  community 

♦ Work  with  suppliers  to  implement  Boeing 
strategies 


7*  &o£s/ve;  cijjp  9 94 

— Factory  Computtng  A/cfrrtectixa  Own  Conlwnce  oe-oom  2t  tQp7  kJilUC 

Expectations  for  Users’  Conference 

♦ Factory  Computing  Architecture  as  an  enabler  in 
implementing  BCAG  Production  Strategies  and 
Initiatives  is  understood 

♦ Agreements,  Issues  and  actions  necessary  to 
converge  towards  the  FCA  Vision  have  been 
documented 

♦ Understanding  of  how  technical  data  will  be  delivered 
to  business  unit  IPTs  via  a Factory  Upgrade 
Process  has  been  started 

♦ Awareness  ot  necessity  to  empower  FCA 

infrastructure  tor  factory  engagement  as  early  as 
possible  l; 


, /r/7r//V/7 


F»cto«y  Comoubng  Arcr»»ocr.>r  Usc-s  Cor-tar»oc»  Orwoo  ?»  ire? 


Critical  Process  and  Computing  Elements  for  Production  Worthiness 
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Slide  2-25 


Deployment  Steps 


Slide  2-26 


Slide  2-28 


Factory  Computnq  Amftaectura  Users  Conleraoce  q~~—  ? 


FCA  Program  Plan 


Umt  Corrf. 
Workshop 

Factory  Architecture 


Domain  To-Be 

'.rt  Protect  ArchJUcturs  Suppfcari’ 

Pt*"*  Trartafton  Plans  Contaranc* 

[ 2 2 2_ 


1/30 


3/30 


2nd  Otr. 


Factory  Upgrade 
Process  Deployment 


Factory  Upgrade  s 

Procaa*  i f'j.  tP T Protect  Raftnamant 

W*9r»a°n  Yxjf  Engagement  * Procat* 

V ? ' V _ V 

2nd  Otr. 


1997 

Program  Plan 


1998  io 
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3.  Vivek  Chandrasekharan 

Slide  3-1 

CATERPILLAR' 


Slide  3-4 


Machine  Tool  Management  & 
Machining  Simulation 


/ 

V nr**  Ch*ndra**kh*r*n  & 

G.  Kstt*f 

Sr.  Mfg.  & Sy«t*m*  Engin*»c 
Mfg.  & Logistic*  Technology  Drv 
T«chf*c*l  Cert*r.  CaUrp^lUrlnc- 


Slide  3-2 


CATERPILLAR 


Mfg.  & Logisbc*  Technology 
Technic*!  Sendee*  Drv i* ion 


Slide  3-5 


Cat’s  View  of  the  Machine  Data  Repository 

• Our  focus  continues  to  be  on  three  areas 
-Process  Planning 

— Machine  performance  data  and  asset  management 
— Simulation 

• Our  progress  since  last  meeting 
-Increased  pressure  from  plants  to  implement 
-Research  partnership  with  Universities  continues 
-Internal  research,  vacation  and  implementation 
— domed  NIST-CRADA  and  collaborative  work 


Slide  3-3 


CATERPILLAR* 


Slide  3-6 


NISTIR  5707  - Modeling  of 
Mfg.  Resources 
Internal  "machine  folders" 
Validation  of  data  models 
Identifying  users  and 
feedback 

Important  characteristics  to 
trend 

Platform  / Implementation 
issues  (layering) 

Link  to  commercial  software 
databases  for  new  machine 
tools 

Feasibility  of 
Implementation 


CATERPILLAR* 


Research  with  Universities 

• Understanding  machine  errors 

• thermal  errors 

• ambient  effects 

• repeatability 

• spindle  analyzer 

• tool  change  repeatability 

• combining  all  errors 

• loaded  conditions 

» correlation  to  part  errors 


CATERPILLAR* 


Internal  Work 

• Validating  data  models,  production  machines 

• Machine  characterization 

• Quasi  static  error  integration 

* machine  metrology  to  std  format 

* simulation  and  validation 

• Correlation  to  part  features 

* rough  operations 
> finish  operations 


CATERPILLAR* 


Work  with  NIST 

• Testing  the  repository 

• successfully  submitted  ball  bar  data 

• comparative  analysis  (ISO  230-1 , ISO  230- 
4) 

> Data  definitions  referenced  from  documents 
provided  at  previous  meeting  (Hans  Soons) 

• Simulation  methods 

• Communications  and  demonstration 
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Slide  3-7 


Slide  3-8 


Slide  3-9 


Slide  3-10 


Analysis 


Slide  3-1 1 


CATERPILLAR 


Recommendations  for  Future 
Work 

• Ball  bar  analysis  from  repository 

• Standardization  of  computing  errors 
► Comparative  analysis 

» Trending  of  errors 

• Supplier  formats 

• Transfer  of  technology  and  demonstration 
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Slide  3-13 


CATERPILLAR'  Slide  3-14  CATERPILLAR 


Recommendations  for  Future  Recommendations  for  Future 

Work  Work 


• Simulation 

• Combining  errors 

• Internal  representation  of  errors  on  CAD  file 

• Visualization 

• Sensitivity  for  machine  correction 


• Laser  characterization  of  machines 

* Reporting  file  formats  from  different 
manufacturers 

* Standardize  file  format 

* Storing  raw  data? 

* Store  data  model  coefficients 
■ Standardize  model 

• Residual  error  (goodness  of  fit) 

• File  format  / data  structure 

> Repeatability  (model,  distribution) 


87 


Appendix 


4.  Sean  Olson 


Slide  4-1 


Error  File  Format 

Linear  Measurement 
File:  1141a001.erl 

Max.  Error:  0.005925 
Max.  Rev.  Err:  0.000468 
Increment : 10.0000 

Travel  Length : 160.000 

Unit  of  Length:  inches 
Air /Mat . Temp . (0F) : 7 8. 0/77 
. 0 

Position:  462.763 

Max. Bi. Rep.:  0.001247 
Date  : 8/26/1997 


Angular  Measurement 
File  1141a001.era 

Max.  Err.  -A- : 5.5 

Max.  Err.  -B- : 7.1 

Increment:  10.000000 
Travel  Length : 160.000000 
Unit  of  Length:  inches 

Straightness  Measurement 

File  1141a001.ers 


Max.  Err.  -XX- : 0.001082 

Max.  Err.  -YY- : 0.001197 
Increment:  10.000000 
Travel  Length:  160.000000 
Unit  of  Length:  inches 
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Slide  4-3 


API 

Winner  Data  Management  System 
Flowchart 


Sp»*lTjr 

Uoohino 

Tool 


Uptiato 

Information 


MaoKIr.*  Toot 


t*V»<TY 
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Interconnection  between  P^rt  idodel. 
Machine  Model.  Machine  Error  Model, 
and  Possible  Corrective  Action*. 


Slide  4-9 
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5.  Don  Esterling 


Techniques  for  Modeling 

CNC  Machine  Errors 

Slide  5-4 

Traditional  (CAD-like) 

Solid  Models 

• Useful  for  modeling  work  cells  (large  scales, 
complex  scene) 

• But  for  metal  removal,  must  choose  between 

Donald  Esterling 

- reasonable  response  time,  fairly  coarse  accuracy 

N-See  Software 

- shop  floor  accuracy,  hours  or  worse  response  time 

Microcompatibles,  Inc. 

for  complex  part  programs 

Objective 

Slide  5-5 

Starting  from 

CAM-Specific  Solid  Modeling 

• A collection  of  shop  floor  CNCs 

• Error  models  for  each  CNC 

• Particular  CNC  pan  program 

• Focus  is  on  metal  removal  process 

• Orders  of  magnitude  faster  than  a CNC 

• Retain  shop  floor  accuracy 

Determine 

•Which  CNC(s)  can  deliver  the  pan 

within  tolerance 

Slide  5-6 

Pixel-Based  Systems 
(Animation) 

N-See  Solid  Model  Verification 

• Accurate  in  view  direction  ( 1 :32,000) 

• Lacks  accuracy  in  screen  X-Y  directions  (1:500) 

• Slow,  Roughly  the  same  speed  as  a physical  CNC 

• Assumes  a “perfect”  machine  tool 

• Will  demonstrate 

- 2 axis  turning 

- 3 axis  milling 

- 4 axis  milling  (indexing) 

- 5 axis  milling  (simultaneous) 
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Slide  5-8 


N-See  Lathe  (Solid  Model) 


Slide  5-11 


N-See  3 Axis  Surfacing  Part 


Slide  5-9 
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Slide  5-13 


Slide  5-14 


Slide  5-17 


Slide  5-15 


Slide  5-18 


Error  Modeling  with  N-See 

• Done  over  a year  ago,  on  experimental 
software 

• Modeled  CNC  hardware  errors  with  NIST 
error  model 

• Turning  Only,  NIST  Demo  Part  Only 

• Demonstrated  feasibility 
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Slide  5-19 


Next  Steps 

•Generalize  to  multiple  turning  centers, 
multiple  parts 

•Provide  a convenient,  automated  comparison 
of  different  turning  centers 
•Milling  Anyone  ??? 
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6.  Joe  Falco 


Slide  6-1 


Slide  6-4 


Slide  6-2 


0.00000 

0.00000 

-0.000700000 

-0.00402000 


Slide  6-5 


Slide  6-3 


Slide  6-6 
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Slide  6-7 


Slide  6-8 
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7.  Debbie  Krulewich 


Slide  7-1 


Slide  7-2 


Debbie  Krulewich 

Lawrence  Livermore  National  Laboratory 

Workshop  on  Development  ot  Machine  Tool 
Performance  Models  and  Data  Repository 

November  20-21 , 1997 


LLNL  a roerested  In  mechine  tool  performance  models  and  data  repository 


L3 


I.To  archive  and  retrieve machne  performance  history 

• CurrenSy  we  um  Lab  View  data  «ct?<Umn  that  records  a header  with 
ueer -specked  rtfcxmahon  (sign  convenbcn.  test  type,  etc.) 

• We  have  no  hotoncaJ  record  that  keeps  track  ot  afl  the  tests  Brat  have 
been  performed. 


2.  To  gamer  generated  Information  about  machine  tool  errors 
- For  error  budgeting  purposes,  we  wc*A3  ike  to  know  typical  errors  tor 
specific  types  of  components 


3.  For  cuffing  force  eenubtwns 

- ft  would  be  useful  to  have  access  to  cuffing  coefficients  for  dttlerent 
materials  and  toots. 


Slide  7-4 


Slide  7-5 


Slide  7-3 
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Slide  7-7 
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8.  Dan  Sawyer 


Slide  8-1 


The  Calculation  of  CMM 
Measurement  Uncertainty 
via  The  Method  of  Simulation  by  Constraints 


S.D.  Phillips,  B.  Borchardl,  D.  Sawyer,  W.T.  Estler, 
D.  Ward,  K.  Ebcrhardt,  M.S.  Lcvcnson,  M.  McClain, 
National  Institute  of  Standards  and  Technology 

B.  Melvin,  ICAMP  Inc., 

T.  Hopp,  ZigZag  Inc., 

Y.  Shen,  G.  W.  University 


Slide  8-4 


Slide  8-2 


Overview 

• Review  CMM  Uncertainty  Concepts 

• Current  Computational  Approaches 

• Concept  of  Simulation  by  Constraint 

• Results:  Uncertainty  vs.  Actual  Errors 


Slide  8-5 


MST  Ijrgc  Seal*  Metrology  Grtup 


Schematic  outlining  the  various  factors  affecting  CMM  measurements. 


TP  12  UNCERTAINTY 


99 


Appendix 


Slide  8-7 


Slide  8-8 


Slide  8-9 


Simulation  Goal 

Calculation  of  Task  Specific  Measurement  Uncertainty  from 
NON-TasK  Specific  CMM  Test  Data 


Slide  8-1 1 


Simulation  by  Constraint  Idea 


Use  Incomplete  Performance  Evaluation  Data 
to  Determine  a Population  of  Possible  CMM  States 
that  arc  Consistent  with  the  Data 


The  Performance  Evaluation  Data  Must  Be  Sensitive 
To  All  the  Kinematic  Errors 
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Slide  8 


Slide  8- 


Slide  8- 


14 


Slide  8-17 


GAGE  MEASUREMENT  EESCRI^’IOX 
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Slide  8-19 


Y Center.  360.  180.  90.  45 
Comp  ON.  XY  Plane.  Run  1,  R5 


Slide  8-22 


Full  Parametric  Simulation 
Flow  Chart 


/wy^  Vxa' 


VvOW\y j 


/\A/\/ 


.i 


W A* 


,V 


Angular  span,  degrees 


Onc-to-One  Mapping 
via  Daia  Fitting  to 
Kinematic  Equations 


One-lo-One  Mapping 
via  Rigid  Body 
Kinematic  Equations 


Onc-to-Onc  Mapping 
ria  Fitting  Algorithm  for 
Substitute  Geometry 


Slide  8-20 


Decision  Rule  (14253-1) 


Slide  8-23 


Simulation  By  Constraint 
Flow  Chart 


Many-to-Onc  Mapping 
via  Data  Fining  to 
Kinematic  Equations 


Onc-to-Onc  Mapping 
via  Rigid  Body 
Kinematic  Equations 


Onc-to-Onc  Mapping 
via  Fining  Algorithm  lor 
Substitute  Geometry 


Slide  8-21 


Example  of  Performance  Evaluation  Data 

ANSI/ASME  B89.4. 1 Values 

Repeatability 

X Linear  Accuracy 

Y Linear  Accuracy 

Z Linear  Accuracy 

Volumetric  Performance 

OfTSet  Probe  Volumetric  Performance 

Poinl-to-Point  Probe  Performance 
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9.  Hans  Soons 


Slide  9-1 


Update  on  the  Data  Dictionary 


Hans  A.  Soons 

Automated  Production  Technology  Division 
National  Instrtute  ol  Standards  and  Technology 

November  20.  1997 


Slide  9-4 


Slide  9-2 


Virtual  Machining 


Virtual  machine  tool : 

A model,  usually  implemented  in  software,  that  predcts  an 
output  of  the  machining  process  by  simulating  the  actions 
of  the  machine  tool  in  response  to  the  pan  program  and  the 
environment. 

Output: 

• Tolerances  part 

• Time  required  to  make  the  part 

• Verification  part  program 

• Tool  life 


Slide  9-5 


Data  Dictionary 


Goal: 

Names  and  cM  nitons  ot  I he  data  elements  thal  can  be 
Retrieved  Irom  a database  ot  machine  tool  performance 
Evaluator  data 

Applications 

• Virtual  machnog 

• Maintenance  ' qualrfy  control 

• Perlormanoe  vertcaton  i comparoor 

Approach: 

• Top  down: 

Try  to  antiopaie  possible  questions 
(Query  to  data) 

• Bottom  Up 

Try  to  model  ail  ruormaior  ot  a perlormanoe  test 
(Dai*  to  quwyi 


(S' 


j AAXyai  | 


| Awyns 


Slide  9-3 

Required  Information 

Slide  9-6 

Performance  Evaluation  Data 

Critical  enabler  is  efficient  access  to  relevant  data  on: 

Currently; 

• The  part  (geometry,  tolerances,  mate nal) 

• Many  formats 

• The  process  plan  (part  program,  setup  and  torturing) 

• The  machine  tod(s) 

• Not  ail  relevant  irriormabon  is  stored 

• The  tod(s) 

Unified  data  definition 

• The  machine  environment 

• Straightforward  nterchange  of  test  data 

Machine  tool  information: 

• Communication  and  storage  of  art  relevant  nformation 

• Data  that  appli—  to  machines  of  a eehee 

T)esign  data’:  ctassrficatxn.  kinematic  model,  axis  and  spmdle  data,  tool 
and  workpiece  management  controller,  accuracy  specifications.  . . . 

• Data  that  applies  to  a aped  he  machine 

* Compensation*,  adjustments 

| • P*rt©fmar»e  *nrak**6on  data  hweta.  p*rts)  | 

i—y-'-A,,  ....  .. ..  . 
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Slide  9-7 


Slide  9-8 


Slide  9-9 


Criteria 

Slide  9-10 

Setup  and  Machine  Motion  Pattern 

• Enable  reconstruction  of: 

Classification  according  to  setup  and  motion  pattern 

• The  nature  of  the  test  and  why.  when,  and  by  whom 

• Angular  or  displacement  measurements  along  a "Ime* *: 

• The  equipment  used  and  settings 

• Geometric  accuracy  of  an  axis  (roll,  pitch,  yaw.  straightness,  positional) 

• The  measurement  setup 

• Dnft  test  of  an  axis 

• The  status  and  motion  pattern  of  the  machne 

• Diagonal  displacement  test 

• Measurement  data 

• Critical  alignments 

• Environmental  conditions 

• Stationary  tests: 

• Etve 

• Efficient  description  of  standardized  and  special  tests 

• Spindle  thermal  stability, 

• Efficient  communication  and  storage  of  user  defined  data 

• Moving  axes  drift,  composite  dnft. 

• No  enforcement  of  information 

• Tool  change  repeatability,  axis  repeatability. 

• Efficient  handling  of  quenes 

• Spindle  error  motion 

• Keep  all  information  of  original  data  files 

• Circular  contouring  tests 

• Compliance  and  hysteresis  tests 

• Express 

• 

Test  Equipment  (Devices  and  Artifacts) 


• Identification,  type,  manufacturer 

• Settings 

• Applied  compensations  and  used  sensorfs) 

• Settle  time  and  trigger  window 

• Number  of  samples  averaged  and  sample  frequency 

• Range/resolution  setting 

• Unit 

• Scale  factor 

• Sign 

• Software  and  software  version 

• Properties 

• Dimensions.  geometry,  reference  feature(s) 

• Material,  effect rve  coefficient  of  expansion 

• Setup 


Slide  9-11 


Machine  and  Environment 


• Status  of  the  machine 

• Applied  compensations 
- • Coolant 

• Clamped  axes 

• Applied  warm-up  procedure 

• Temperatures 

• Status  of  the  machine  environment 


Slide  9-12 
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Slide  9-13 

Example  1 

Slide  9-16 

Example  1 

Po&toomng  accuracy  of  a hnear  axis  usrtg  a laser  interferometer 

"|::4 

M-I.ur;..  • *r  /.  In » rn«*  *iiofmjton  m ipn 

7..*  — 1.-.  ’ ^ ' 

r -j  . - ‘ «o  *n«3  ,«>*c*,on  Ufclw. 

: A v:".:.. . 

1 ’ * - 

Slide  9-14 


Example  1 

Slide  9-17 

Example  1 

: — 

- - :L 

Slide  9-15 


Example  1 

Slide  9-18 

Example  1 

Tri  . 

7rl77*r_wJnS:» 

mr?»T.»*ni:r 

J.r, . 
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Slide  9-19 


Example  1 


Slide  9-22 


Slide  9-20 

Example  2 

Slide  9-23 

Discussion 

• Focus: 

T,,.. 

• Should  we  concentrate  on  higher  levels  of  the  database 

-r  i.  • 

• Is  this  level  of  detail  desired 

Cf ’ " 

• Should  there  be  a closer  link  to  the  database  design 

• Should  there  be  a closer  link  to  (existing)  data  file  formats 

; 

• Should  we  restrict  ourselves  to  standardized  tests 

• Top  down  (query  to  data)  vs  bottom  up  (data  to  query)  approach 

• ••  . . .... 

• Are  essential  elements  missing 

• *•- 

• Existing  databases  / approaches 

• How  to  improve  the  organization 

• "StandardizecT  tools  (EXPRESS) 

• How  to  increase  participation  and  when 

_ ^ ..  . 

Slide  9-21 
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10.  Larry  Welsch 


Slide  10-1 


Update  on  the  Repository 

Lawrence  A.  Welsch,  Ph.D. 
Lawrence.  Welsch  @ nist.gov 

f^Jisrr 
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Yesterday 


Platform 

- Hardware 

- Software 

- Portability 
CGI 

- PERL 

- KSH 

Analysis  - MATLAB 


Data  Base 

- Clear  Text 

- Linear  Search 
Design 

- Classic  Web 

- Functionality  (Barely) 


rsiisr 


Slide  10-2 


Status  and  Plans 

• Software  Framework 

• Yesterday 

• Today 

• Tomorrow 

• Day  after  tomorrow 

• Issues 

NIST 

LA*: 

Slide  10-5 


Today 

• Platform 

• Data  Base  - 

- Hardware 

MATLAB 

- Software 

• Design 

- Portability 

- MATLAB  centric 

• CGI 

- Functionality  (limited) 

- SAY 

. 

- MATLAB 

• Analysis  - MATLAB 

— 

NIST 

Slide  10-6 

Software  Framework 

Tomorrow 

• Platform 

• Platform  - SAT  * Design 

• CGI  Scripting  Tools 

• Analysis  Tools 

. CGI  - Classic  Web 

- PERL  + ODBC  - Classic  Data  Base 

_ «SH  - Functionality  (limited) 

• Data  Base  Tools 

• Analysis  - MATLAB 

• Design 

• Data  Base 

- MS  SQL  Server 

- ODBC 

NIST  L*" 

'=»"  NI<A1  ' 
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Day  After  Tomorrow 

Slide  10-8 

Issues 

• Platform  - SAT  • Design 

• Functionality  / Design 

• CGI  - SATM  - Data  Base  Centric 

• Management 

• Analysis  “ Functionality 

« n Extensible 

• Security 

- MATLAB 

- TBD 

• Cooperation 

• Data  Base 

• Other 

• Data  Base 

- Distributed  (ODBC) 

rsiusT 

rsjisrr  — 

108 


Appendix 


11.  Richard  Johnson 


Slide  1 1-1 


Design ► Build  — — ♦ Consume 


Slide  1 1-4 


Design ► Build ► Consume 


Slide  11-2 


Slide  1 1-5 


Slide  11-3 


Slide  1 1-6 
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Slide  11-7 


12.  Road  Map 


Slide  12-1 


Slide  12-4 

Machine  Tool  Performance  Models 

How  do  we  get  there? 

and 

Machine  Data  Repository 

• Data  Dictionary,  formats  and  info 

models  for  quasi-static  machine  tool 

A Draft  Road  Map 

performance  and  resulting  Repository 
(including  environmental  info,  physical 

machine  description,  and  uncertainties) 

Alkan  Donmez 

- FY98 

• Data  analysis  tools  - FY98  - 99 

Project  Technical  Leader 

• Simulation  tools  --  FY99 

Slide  12-5 

Key  Questions 

How  do  we  get  there? 

• Can  it  be  made? 

• Performance  tracking  tools  - FY98  - 00 

• How  can  it  be  made? 

• Capability  evaluation  (Cpk)  tools  - 

• How  can  it  be  made  competitively? 

FY00 

• How  can  it  be  kept  that  way? 

• Inspection  analysis  tools  - FY01 

• Dynamic  models  integration  - FY02 

• Machine/process  model  integration  - 

FY03 

Slide  12-3 


Tools  needed 

• Tolerance  budgeting 

• Process/asset  planning 

• Capability  analysis  (Cpk) 

• Machine  simulation 

• Process  simulation 

• Inspection  planning  and  simulation 

• Machine  maintenance  (performance 
tracking) 


Appendix  II  - Time  Line  resulted  from  Discussions 


Appendix  III  - MIMETEK  PART  AND  PROCESS  MONITORING  AND  ARCHIVING 

SYSTEM 
Richard  Jennings 
ICAMP  and  MIMITEK 


It  is  possible  to  use  inspection  data  to  characterize  and  monitor  the  dimensional  “behavior”  of 
machine  tools  and  Coordinate  Measuring  Systems  (CMS)  and  their  associated  software.  NIST’s 
ATEP-CMS  is  providing  very  interesting  independent  assessment  of  CMS  data  analysis  software 
and  ICAMP  provides  commercial,  independent,  and  rapid  data  analysis  software  which  can  be 
used  with  CMS  and  machine  tool  sensors. 

Think  of  a machine  tool  or  CMS  as  having  three  major  components  and  one  very  important 
option: 

1)  hardware  platform, 

2)  motion  controller, 

3)  cutting  tool  or  sensor,  and 

4)  optional  data  analysis  software 

The  machines  can  be  mapped  and  certified  for  point-to-point  travel  and  point  location 
measurement  using  B89  procedures  and  this  “mapping”  can  become  a reference. 

With  a known  “good”  machine,  we  can  measure  an  artifact  placed  in  the  workspace  and  record  all 
of  the  point  readings  from  the  artifact  surface.  Artifacts  can  range  from  reference  spheres  to  the 
B5.54  “test  part”  to  proprietary  artifacts.  The  measurements  on  the  artifact  are  archived  as  a 
reference  “standard.”  At  any  time,  the  Reference  artifact  can  be  re-measured  and  the  latest 
measurements  compared  to  the  reference.  Renishaw  adopted  this  procedure  for  on-machine  tool 
inspection  several  years  ago. 

We  want  to  compare  measurements  made  on  the  artifact  data  at  this  time  with  measurements 
made  at  the  time  of  establishing  the  reference.  We  want  to  determine: 

A)  Are  there  changes  in  computed  GD&T  measurements  as  well  as  location,  size,  and  shape? 

B)  Which  surfaces  are  exhibiting  changes? 

C)  How  much  have  the  measurements  changed? 

D)  Do  the  changes  in  the  new  measurements  exceed  acceptable  limits  (tolerance  boundaries)? 

MIMETEK  will  work  with  the  customer  to  determine  the  acceptable  “tolerance”  boundaries  for 
individual  surfaces  on  the  artifact.  In  fact,  we  can  establish  “interim”  boundaries  (before  parts  are 
lost,  so  that  we  can  raise  a “caution”  flag  to  signal  the  eminent  need  for  corrective  action. 

We  have  done  a good  deal  of  work  with  the  B5.54  test  plate  for  machine  tool  performance 
evaluation  and  we  have  established  that  more  complex  artifacts,  such  as  the  B5.54,  can  serve  as  a 
“viewing  amplifier”  to  highlight  problems. 

In  preliminary  tests  using  commercial  e-mail  and  Internet  services  during  the  10:00  Am  to  4:00 
PM  period,  the  elapsed  time  including  sending  probe  data  from  a customer  to  MIMETEK  and 
returning  printed  reports  and  picture  diagnostics  to  the  customer  site  has  been  less  than  one  hour 
when  we  are  working  with  inspection  data  on  a known,  commercially  available  artifact.  This 
prototype  process  is  not  automated  yet,  but  we  would  expect  to  be  able  to  maintain  the  less-than- 
one-hour  turnaround  time  for  priority  service. 
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This  procedure  can  also  be  set  up  on-site  for  faster  turn  around  and  only  the  results  need  than  be 
sent  to  MIMETEK  for  archiving  and  possible  trend  analysis.  Data  sets  and  results  would  be  date 
and  time  stamped.  For  high  throughput  operations  such  as  cylinder  machining  on  automotive 
engine  blocks,  on-site  processing  is  a necessity  but  even  then  it  can  be  backed  by  remote 
“auditing"  at  MIMETEK’ s archival  center. 

Artifact  measurement  can  be  done  on  both  CMMS  (of  any  sensor  type)  and  on  machine  tools.  It 
is  useful  to  note  that  CMMS  are  not  viewed,  as  being  production  tools  so  “down  time”  is  not 
perceived  to  be  a problem.  Machine  tools  that  are  sitting  idle  while  inspection  data  is  collected 
with  the  probing  systems  that  now  come  standard  with  most  machine  tools  cause  great  distress  in 
management  ranks.  Better  to  be  cutting  scrap  than  to  be  idle. 

At  MIMETEK,  we  are  satisfied  that  are  probing  sub-systems  from  Renishaw  or  Marposs  on 
machine  tools  can  do  an  acceptable  job  of  data  collection  and  that  we  can  install  robust  data 
analysis  software  from  ICAMP  on  new  machine  tool  controllers  or  we  can  pass  inspection  data 
from  the  machine  tool,  over  RS-232,  RS-422,  or  fiber  optic  LAN  to  separate  computers  on  the 
shop  floor,  or  we  can  send  the  data  over  the  Internet  to  MIMETEK  for  analysis. 

The  machine  tools  can  continue  to  throw  off  chips,  satisfying  the  psychological  needs  of 
management,  but  the  date  and  time  stamped  inspection  data  collected  on  the  machine  tools  can  be 
analyzed  off-line  and  when  unacceptable  deviations  are  found,  the  process  can  be  stopped  for 
corrective  action  on  the  machine  tool. 

At  MIMETEK,  we  believe  that  the  “10:1”  rule  on  CMM  vs.  machine  tool  accuracy  is  a Trojan 
Horse  and  that  the  (usually  audited)  accuracy  of  Data  Analysis  software  has  a much  greater 
impact  on  measurement  accuracy  and  reconciliation. 

We  believe  that  by  using  independent  Data  Analysis  software  like  ICAMP’ s,  whose  accuracy  can 
be  easily  established,  we  can  use  both  artifact  inspection  and  “real”  part  inspection  on-machine  in 
the  future.  This  will  be  especially  attractive  for  expensive  or  thin  walled  parts  which  must  now 
be  cycled  from  machining  center  to  inspection  and  back. 

Parts  processed  during  the  interim  can  be  shunted  to  the  inspection  (CMM)  area  for  checking  to 
see  if  these  parts  can  be  salvaged  (if  they  are  expensive)  and  to  “audit”  the  results  reported  by 
MIMETEK. 

Individual  time  and  date  stamped  data  sets  for  a common  artifact  collected  on  a particular 
machine  can  be  archived  at  MIMETEK  and  trend  analysis  could  be  periodically  performed  to 
identify  recommended  maintenance  frequency. 

Much  work  remains  to  be  done  in  system  integration,  but  the  basic  technologies  are  available  now 
and  can  be  customized  for  each  customer’s  needs. 

If  you  have  questions  or  comments,  please  contact  Richard  Jennings  at  MIMETEK  and  ICAMP 
at 

(860)  643-1711  or  e-mail  us  at  mimetek@connix.com. 

MIMETEK  works  with  individual  companies  on  a consulting  basis  to  establish  the  best  possible 
procedures  for  inspection,  auditing,  and  archiving  of  machine  and  part  characterization  data. 
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